[ERR] Re: Post-authentication tasks
Transmit Report: To: [EMAIL PROTECTED], 402 Local User Inbox Full ([EMAIL PROTECTED]) ---BeginMessage--- If this is not an appropriate list to ask design questions, could someone point me to a more suitable resource? Perhaps the tomcat-dev list? Thank you, -Sasha Borodin On 7/28/03 11:35, Sasha Borodin [EMAIL PROTECTED] wrote: I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. Thanks for any suggestions. -Sasha Borodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message---
[ERR] Post-authentication tasks
Transmit Report: To: [EMAIL PROTECTED], 402 Local User Inbox Full ([EMAIL PROTECTED]) ---BeginMessage--- I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. Thanks for any suggestions. -Sasha Borodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message---
Post-authentication tasks
I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. Thanks for any suggestions. -Sasha Borodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post-authentication tasks
If this is not an appropriate list to ask design questions, could someone point me to a more suitable resource? Perhaps the tomcat-dev list? Thank you, -Sasha Borodin On 7/28/03 11:35, Sasha Borodin [EMAIL PROTECTED] wrote: I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. Thanks for any suggestions. -Sasha Borodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post-authentication tasks
AFAIK, this is the appropriate list. You could try tomcat-dev, but that is more for discussions about developing Tomcat itself, not using Tomcat. If you haven't received a reply here, it is most likely because nobody has an answer. People here are pretty good about responding whenever they can help. It might take a day or two, as welllots of people are on holiday for the summer. John Sasha Borodin wrote: If this is not an appropriate list to ask design questions, could someone point me to a more suitable resource? Perhaps the tomcat-dev list? Thank you, -Sasha Borodin On 7/28/03 11:35, Sasha Borodin [EMAIL PROTECTED] wrote: I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. Thanks for any suggestions. -Sasha Borodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post-authentication tasks
I did this with a filter. Happens on each requests, but the performance was acceptable. Another alternative is to extend the Realm you are using to meet your needs. Larry [EMAIL PROTECTED] 07/28/03 1:53 PM AFAIK, this is the appropriate list. You could try tomcat-dev, but that is more for discussions about developing Tomcat itself, not using Tomcat. If you haven't received a reply here, it is most likely because nobody has an answer. People here are pretty good about responding whenever they can help. It might take a day or two, as welllots of people are on holiday for the summer. John Sasha Borodin wrote: If this is not an appropriate list to ask design questions, could someone point me to a more suitable resource? Perhaps the tomcat-dev list? Thank you, -Sasha Borodin On 7/28/03 11:35, Sasha Borodin [EMAIL PROTECTED] wrote: I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post-authentication tasks
Larry, Did you apply the filter to all requests or were you successful in assigning it only to the j_security_check URL? If you were successful, what version of Tomcat are you running? Thanks, -Sasha Borodin On 7/28/03 14:59, Larry Meadors [EMAIL PROTECTED] wrote: I did this with a filter. Happens on each requests, but the performance was acceptable. Another alternative is to extend the Realm you are using to meet your needs. Larry [EMAIL PROTECTED] 07/28/03 1:53 PM AFAIK, this is the appropriate list. You could try tomcat-dev, but that is more for discussions about developing Tomcat itself, not using Tomcat. If you haven't received a reply here, it is most likely because nobody has an answer. People here are pretty good about responding whenever they can help. It might take a day or two, as welllots of people are on holiday for the summer. John Sasha Borodin wrote: If this is not an appropriate list to ask design questions, could someone point me to a more suitable resource? Perhaps the tomcat-dev list? Thank you, -Sasha Borodin On 7/28/03 11:35, Sasha Borodin [EMAIL PROTECTED] wrote: I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Post-authentication tasks
I've vaguely uncomfortable suggesting it, but how about using a Session Listener ? You could have a class implement the javax.servlet.http.HttpSessionListener interface, and be notified of such events as creation, invalidation and time-out of the session. If CMA is accomplished through sessions (which for Tomcat and form-auth, I believe it is) you can do your post-auth setup here. Potential problems: Where in the AUTH process does the session get created? Does Tomcat create a session, even if the AUTH failed? This would invalidate this whole idea. The creation of a session object would no longer imply that the session owner is Authenticated. Also, what happens with session timeouts ? Are there issues to be aware of here? Concurrency: Your listener class would be invoked by the container and if your post-auth tasks took a long enough time, a user might click something on the interface (that they got to after being AUTH'd), and perhaps the post-auth setup has not completed yet. Are you convinced that a filter would be too much load ? The filter could simply test for the existence of one of your post-auth objects, and if it's missing, do the post-auth. Else, do nothing. Well crafted and well placed if/elses needn't add that much overhead. Is there a single point of entry to your app? How about a short piece of code here to do the post-auth? Finally, it just occurs to me that if you knew what Tomcat places into the session to indicated an Authenticated user, you could use an javax.servlet.HttpSessionAttributesListener class to listen for that particular attribute. This might be much safer than using a SessionListener, but probably far less portable, as each Container is free (or are they?) to implement CMA as they want, using whatever keys they want. -Original Message- From: Sasha Borodin [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 11:35 AM To: Tomcat Users List Subject: Post-authentication tasks I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. Thanks for any suggestions. -Sasha Borodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post-authentication tasks
I do all requests on version 4.1.24 of tomcat. Larry [EMAIL PROTECTED] 07/28/03 2:26 PM Larry, Did you apply the filter to all requests or were you successful in assigning it only to the j_security_check URL? If you were successful, what version of Tomcat are you running? Thanks, -Sasha Borodin On 7/28/03 14:59, Larry Meadors [EMAIL PROTECTED] wrote: I did this with a filter. Happens on each requests, but the performance was acceptable. Another alternative is to extend the Realm you are using to meet your needs. Larry [EMAIL PROTECTED] 07/28/03 1:53 PM AFAIK, this is the appropriate list. You could try tomcat-dev, but that is more for discussions about developing Tomcat itself, not using Tomcat. If you haven't received a reply here, it is most likely because nobody has an answer. People here are pretty good about responding whenever they can help. It might take a day or two, as welllots of people are on holiday for the summer. John Sasha Borodin wrote: If this is not an appropriate list to ask design questions, could someone point me to a more suitable resource? Perhaps the tomcat-dev list? Thank you, -Sasha Borodin On 7/28/03 11:35, Sasha Borodin [EMAIL PROTECTED] wrote: I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post-authentication tasks
Where in the AUTH process does the session get created? Does Tomcat create a session, even if the AUTH failed? This would invalidate this whole idea. The creation of a session object would no longer imply that the session owner is Authenticated. From my observations, a session is created (and cookie sent to browser) as soon as the login form is requested (before the authentication takes place). So this would make a SessionListener not useful unfortunately. Are you convinced that a filter would be too much load ? Is there a single point of entry to your app? How about a short piece of code here to do the post-auth? I the overhead would be negligible (compared to some of my other design choices :-), but I always try to eliminate extra work for the app when possible. If I can figure out a way to catch the authentication, rather than check every request, I'd be happier... Finally, it just occurs to me that if you knew what Tomcat places into the session to indicated an Authenticated user, you could use an javax.servlet.HttpSessionAttributesListener class to listen for that particular attribute. That is precisely what I'm investigating. I'm trying to figure out if and under what key Tomcat stores the user Principal upon authentication in the session. If I can figure this out (I'm sifting through the code right now), I can set up an HttpSessionAttributesListener to look for the binding of that attribute, and fire off my post-login tasks based on that event. However, a big drawback would be if the key name, or Object class were container specific - I'm trying to keep the app container-neutral, other than my realm classes. I have not found any implementation details concerning this in the Servlet spec document, so I'm afraid it's up to the vendor. If anyone's got some light to shed on user Principal storage and standardization, please drop us a line. Thank you! -Sasha Borodin -Original Message- From: Sasha Borodin [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 11:35 AM To: Tomcat Users List Subject: Post-authentication tasks I'd like to get some suggestions for performing post-authentication tasks while using Container Managed Authentication. Craig Berry suggested a filter that checks the session for necessary attributes, and creates them if they're missing. This check would be performed on every request however. Has anyone implemented a different approach to this problem? I'd like to find a solution in which the extra tasks are performed just ONCE, somehow triggered by the container authentication. Please reference my previous post on a filter vs. session attribute listener approach. Thanks for any suggestions. -Sasha Borodin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Post-authentication tasks
Sasha Borodin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Where in the AUTH process does the session get created? Does Tomcat
create a session, even if the AUTH failed? This would invalidate this
whole idea. The creation of a session object would no longer imply that
the session owner is Authenticated.
From my observations, a session is created (and cookie sent to browser) as
soon as the login form is requested (before the authentication takes
place).
So this would make a SessionListener not useful unfortunately.
Are you convinced that a filter would be too much load ?
Is there a single point of entry to your app? How about a short piece
of code here to do the post-auth?
I the overhead would be negligible (compared to some of my other design
choices :-), but I always try to eliminate extra work for the app when
possible. If I can figure out a way to catch the authentication, rather
than check every request, I'd be happier...
Finally, it just occurs to me that if you knew what Tomcat places into
the session to indicated an Authenticated user, you could use an
javax.servlet.HttpSessionAttributesListener class to listen for that
particular attribute.
That is precisely what I'm investigating. I'm trying to figure out if and
under what key Tomcat stores the user Principal upon authentication in the
session. If I can figure this out (I'm sifting through the code right
now),
I can set up an HttpSessionAttributesListener to look for the binding of
that attribute, and fire off my post-login tasks based on that event.
Tomcat doesn't store the user Principal as an Attribute to the session. It
stores it in a seperate structure that is only accessible to Tomcat internal
classes. You're best bet is something like:
void doFilter(ServletRequest request, ServletResponse response, FilterChain
chain)
throws IOException, ServletException {
HttpServletRequest hRequest = (HttpServletRequest)request;
HttpSession session = request.getSession(false);
if( session != null ) {
Principal myPrincipal =
(Principal)session.getAttribute(com.whoissasha.user.principal);
if(myPrincipal == null ) {
myPrincipal = hRequest.getUserPrincipal();
if( myPrincipal != null) {
session.setAttribute(com.whoissasha.user.principal,
myPrincipal);
processPostLogin(request, response);
}
}
chain.doFilter(request, response);
}
However, a big drawback would be if the key name, or Object class were
container specific - I'm trying to keep the app container-neutral, other
than my realm classes. I have not found any implementation details
concerning this in the Servlet spec document, so I'm afraid it's up to the
vendor.
If anyone's got some light to shed on user Principal storage and
standardization, please drop us a line.
Thank you!
-Sasha Borodin
-Original Message-
From: Sasha Borodin [mailto:[EMAIL PROTECTED]
Sent: Monday, July 28, 2003 11:35 AM
To: Tomcat Users List
Subject: Post-authentication tasks
I'd like to get some suggestions for performing
post-authentication tasks while using Container Managed
Authentication.
Craig Berry suggested a filter that checks the session for
necessary attributes, and creates them if they're missing.
This check would be performed on every request however.
Has anyone implemented a different approach to this problem?
I'd like to find a solution in which the extra tasks are
performed just ONCE, somehow triggered by the container
authentication. Please reference my previous post on a
filter vs. session attribute listener approach.
Thanks for any suggestions.
-Sasha Borodin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
