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