RE: Re: J2EE Security issue...
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
RE: Re: J2EE Security issue...
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/
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
Re: J2EE Security issue...
You might try to make a custom UserManager that delegates to the default one, and then performs some actions. Aaron Tavistock wrote: 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?
