Another way for security check is to use the new
filter feature added in servlet 2.3 or JSP 1.2 specs.
--- Satter, Rabi [EMAIL PROTECTED] wrote:
Is there any reason why you don't update the object
when a change is made?
That is how we are currently do it. That way I don't
have to check for
changes.
Just curious if I am missing some hidden issue that
will only come out and
byte me later.
-Original Message-
From: Jeff Hubbach [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 3:47 PM
To: Orion-Interest
Subject: Fw: Re: J2EE Security issue...
repost..
One thing we added to what Rabi is doing is as
follows:
We track version with each object. If the user
object is already on the
session
then we get it off and double-check to make sure
that the version on the
session
is the most up-to-date. If it isn't, then we refresh
that object on the
session
with what's in the database. This way we're
guaranteed to have the
most-recent
user information on the session.
This is all done in a filter that is mapped to
everything, providing
post-login
processing.
Jeff.
On Wed, 13 Mar 2002 09:25:09 -0600
Satter, Rabi [EMAIL PROTECTED] wrote:
I had the same issue. We did do it as a filter.
However we checked to see
if
the a user context object (ie object where the
informaiton was stored)
existed in the session. If not then checked to see
if the user was logged
in. If not then skip setting up the object. Works
pretty good.
-Original Message-
From: Aaron Tavistock [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 1:44 PM
To: Orion-Interest
Subject: J2EE Security issue...
We've been using J2EE based security for some time
now, its working great
for us supporting several hundred users
distributed across a handful of
servers.
Heres my issue - I have a set of things that
happen on every page, a
portion
of which is looking for a 'new' login which then
launches a series of
things
including doing database lookups, dropping stuff
in the session, etc.
Its occured to me that it would be significantly
more effective if this
was
chained off the J2EE authentication, instead of
checking on each page. I
started looking into it and it looks like 1) its
not part of the spec and
2)
Orion has no specific implementation. The
current implementation of J2EE
security is so completely handled by the container
that theres no way to
get
something in there.
I then started going down the question of 'what is
J2EE security except a
filter?', so I could potentially chain a filter
through there? It doesn't
solve the problem because it still happens on each
page hit.
Anyone have any ideas on the best way to do
'postprocessing' when the user
is authenticated?
--
Jeff Hubbach
Internet Developer
Sun Certified Web Component Developer
New Media Division
ITQ Lata, L.L.C.
303-745-4763 x3114
--
Jeff Hubbach
Internet Developer
Sun Certified Web Component Developer
New Media Division
ITQ Lata, L.L.C.
303-745-4763 x3114
__
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/