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.
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".
