Maybe I don't understand the requirement, but wouldn't a front controller on
the web tier be a more suitable place to cache the result of authentication,
using a session area perhaps?
Ken
>
>On Wed, 26 Sep 2001, Evan Ireland wrote:
>
>> Matthew,
>>
>> What about having a 'timeout' instance variable inside a stateful
>> session bean that you check, only going to the DBMS if the timeout
>> has occurred?
>>
>> If your admin user changes something, is it ok to have a possible
>> time delay before this takes effect (e.g. 1 minute or 10 minutes).
>> If so, the stateful session bean can work out ok.
>
>Our requirements on this are still a bit fuzzy so I'm not sure if the
>timeout method would work for us. I will keep it in mind though.
> Thanks for the input,
> -M@
>
>> Matthew Hixson wrote:
>>
>> > Do you do authentication on every single method call? That is what we're
>> > thinking about doing. The problem is that if we place a boolean flag
>> > inside a statefull session bean to indicate that the user has been
>> > authenticated (using another stateless session bean) then that flag can
>> > become dirty if an administration app decides to disable that user's
>> > account.
>> > This dirtiness problem can be gotten around by using a stateless session
>> > bean to authenticate the user, but making a trip to the db on every method
>> > call just to authenticate the user (let alone how many db calls it might
>> > take to perform the business logic) seems rather expensive.
>> > I was thinking that it might make sense to represent the user's
>> > authentication information with an entity bean. This way administration
>> > software that manages users' accounts and client software that
>> > authenticates the users can be kept in sync. If a user is logged in to
>> > our web application and an administrator disable's that user's account
>> > then the next action attempted by the user would be disabled. We much
>> > prefer this over allowing the user to keep doing whatever they want until
>> > they logout and attempt to login again.
>> > Anyone care to comment on this problem?
>> > -M@
>> >
>> > --
>> > Matt Hixson
>> > Aventail Corporation
>> > Seattle, Washington
>> > www.aventail.com
>> >
>> > On Tue, 25 Sep 2001, Senthoorkumaran wrote:
>> >
>> >
>> >>I think using a session bean in this case is better. Keep it stateless
>> >>too if possible. What we have done is written a Oracle package which
>> >>will authenticate the user and at the same time will returns some
>> >>necessary field to the front end in the same call which we will be
>> >>working with. For example the use name and password could be passed and
>> >>may be if it is authorized user we could send back
>> >>SessionTimeoutInterval, FirstName, LastName.
>> >>
>> >>We are using session bean for this purpose and it works well.
>> >>
>> >>Senthoor
>> >>
>> >>
>> >> -----Original Message-----
>> >>From: A mailing list for Enterprise JavaBeans development
>> >>[mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Hixson
>> >>Sent: Tuesday, September 25, 2001 5:46 AM
>> >>To: [EMAIL PROTECTED]
>> >>Subject: representing login info with entity beans?
>> >>
>> >>I am working on a project where we need to repeatedly authenticate
>> >>access
>> >>to a session bean method. Due to some technical restrictions we can't
>> >>use
>> >>cookies to authenticate a session. Some piece of client software may
>> >>need
>> >>to access the same session bean method a hundred times in a row, but we
>> >>have no way of knowing (from the server side) whether or not those
>> >>requests are coming from the same client. There also may be many
>> >>clients
>> >>accessing the same method at the same time.
>> >> Username and password information is stored in a database. Would it
>> >>significantly increase performance to represent the username/password
>> >>information with an entity bean so that the container can cache that
>> >>information instead of making a trip to the db each time?
>> >> Anyone else out there had to solve a similar problem?
>> >> -M@
>> >>
>> >>--
>> >>Matt Hixson
>> >>Aventail Corporation
>> >>Seattle, Washington
>> >>www.aventail.com
>> >>
>> >>========================================================================
>> >>===
>> >>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>> >>body
>> >>of the message "signoff EJB-INTEREST". For general help, send email to
>> >>[EMAIL PROTECTED] and include in the body of the message "help".
>> >>
>> >>
>> >
>> > ===========================================================================
>> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>> > of the message "signoff EJB-INTEREST". For general help, send email to
>> > [EMAIL PROTECTED] and include in the body of the message "help".
>> >
>> >
>> >
>> >
>>
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
