Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Thanks to Mark and Chris for all suggestions. I thing that a will follow th Chris suggestion to re-architect my session. I was attracted by this piece of code in Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem lynckmeister Wed, 11 Feb 2009 06:32:43 -0800 public class SessionTimeoutFilter implements Filter { private final Log logger = LogFactory.getLog(SessionTimeoutFilter.class); private String timeoutPage = timeout.html; public void init(FilterConfig filterConfig) throws ServletException { } public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException { if ((request instanceof HttpServletRequest) (response instanceof HttpServletResponse)) { HttpServletRequest httpServletRequest = (HttpServletRequest) request; HttpServletResponse httpServletResponse = (HttpServletResponse) response; // is session expired control required for this request? if (isSessionControlRequiredForThisResource(httpServletRequest)) { String requestedID = httpServletRequest.getRequestedSessionId(); // is session invalid? HttpSession session = httpServletRequest.getSession(); String sID = session.getId(); String nochmalID = httpServletRequest.getQueryString(); // ok this is allways false , means the session is allways valid. sure it is, but its a new one ! boolean isSessionInValid = (requestedID != null) !httpServletRequest.isRequestedSessionIdValid(); Object testObject = session.getAttribute(ISVALID); // here I tried some things... the isSessionInValid flag doesnt help b/c the session is allways valid // the testObject is allways null b/c if the user comes from the loginpage the user is not set in the first time // with the code like this, we're allways redirected in an constant loop. // besides that I think redirection is not the right way to handle , I mean, // i feel the right solution would recognize that the session is not in a proper state and than // delete the request wich allways causes in that crash. but how? and wich restored information exactly is the wrong one ? if (testObject == null /* isSessionInValid*/ ) { String timeoutUrl = httpServletRequest.getContextPath() + / + getTimeoutPage(); logger .info(session is invalid! redirecting to timeoutpage : + timeoutUrl); and in particular: String requestedID = httpServletRequest.getRequestedSessionId(); HttpSession session = httpServletRequest.getSession(); String sID = session.getId(); so i thought that was possible to 'trigger' a re-logon after timeout plus the reference of both expired session (requestedID) and new session (sID); if there was a way to copy some attributes from the old session to the new one i solved my problem. But seems to me that the old session non more exists at this point of the request flow. Is this true? Alberto. -- View this message in context: http://www.nabble.com/Re%3A-Tomcat-Realm-Auto-Relogin-after-Session-Timeout-Problem-tp25479941p25507329.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alberto, On 9/18/2009 7:42 AM, atroiano wrote: But seems to me that the old session non more exists at this point of the request flow. Is this true? Correct: by the time you can detect a new session, the old session is totally gone. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqzrf8ACgkQ9CaO5/Lv0PChdQCdHk7dNF384dqp13cwf75+eua1 PWQAni9LlasXWE0byaviZjrZnPeGaj9t =zpcv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Christopher Schultz-2 wrote: This is a question that you will have to answer: what information is absolutely necessary for you to resume a user interaction in-progress? Whatever that is, you'll need to include that information in every single link that a user can click on (or in every form they can submit). The problem is that to resume a user interaction in-progress after a re-login I need informations binded as attributes in the expired session. After a re-login I would like to 'resume' old session instead of to use e new empty one. Is it possible? Alberto -- View this message in context: http://www.nabble.com/Re%3A-Tomcat-Realm-Auto-Relogin-after-Session-Timeout-Problem-tp25479941p25487080.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
atroiano wrote: Christopher Schultz-2 wrote: This is a question that you will have to answer: what information is absolutely necessary for you to resume a user interaction in-progress? Whatever that is, you'll need to include that information in every single link that a user can click on (or in every form they can submit). The problem is that to resume a user interaction in-progress after a re-login I need informations binded as attributes in the expired session. After a re-login I would like to 'resume' old session instead of to use e new empty one. Is it possible? The way you describe? No. If you want this then you have a couple of options: a) Do what Chris said and pass state back and forth in the request/repsonse b) Buy more memory and have longer session expiration times c) Look into using the persistent session manager Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 9/17/2009 4:56 AM, Mark Thomas wrote: atroiano wrote: Is it possible? The way you describe? No. +1 If you want this then you have a couple of options: a) Do what Chris said and pass state back and forth in the request/response More specifically, architect your session such that a few pieces of information can re-create the session state, rather than having to encode /all/ session state in the URL (otherwise, you'd never need the session, now, would you?). Here is a concrete example: we deliver questionnaires on-line to respondents. If their session times out in the middle of taking a questionnaire, we want them to be able to resume right where they were. We put the id of the questionnaire they are taking right into the URLs of any links, and into any forms they can submit (answering a question submits a form, so usually we're talking about POST parameters here). If the session times out, the next request (after successful authentication, that is) will have nothing available but the questionnaire id. The code that manages the questionnaire will look for the session objects, and, not finding them, will take the id from the request, reconstruct everything in the session necessary to continue the questionnaire in-progress (because the state of the /questionnaire/, not the session itself, is stored in our database), and then resume the questionnaire. So, although we have a bunch of information stored in the session in order to deliver the questionnaire quickly, the disappearance of the data in the session is tolerable: we simply recover by re-building the session information given that one special request parameter. Of course, you have to architect your application to work this way. There is no special configuration option for Tomcat (nor any other app server for that matter) that can simple recover your session for you after it expires. b) Buy more memory and have longer session expiration times c) Look into using the persistent session manager There's another option if you want drop-in session recovery. It's a giant hack, won't work except under the best of circumstances, and probably counts as bad design (it IS a giant hack), but you could: 1. Make sure everything in your session is Serializable (always a good thing) 2. Make sure every URL you use is run through response.encodeURL() (including form actions!) 3. Write a filter that does the following: a. Wraps the response in a special subclass of HttpServletResponseWrapper (see below) b. Checks for the presence of a session, then checks the session for a magic attribute (say, SESSION_CONFIGURED or whatever) c. If the magic attribute does not exist, recovers the session (see below) d. Calls the next filter in the chain 4. Write an HttpServletResponseWrapper that overrides encodeURL and encodeRedirectURL to do the following: a. Serialize all session attributes to a GzipOutputStream, then encrypt them using some decent encryption algorithm (such as 3DES, Blowfish, etc.), then add this data to the URL in a unique parameter like SESSION or whatever. Session recovery is simple: just decrypt the SESSION request parameter, deserialize the data, and shove it into the session. Instant session recovery. Here are some potential problems: * See #1 and #2 above * If you have a lot of session data, you may exceed the URL length limit * Performance will suffer due to all that encryption being done for every URL you generate But, if you have small session data, this might work. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqyZVcACgkQ9CaO5/Lv0PB8QgCfVfRlAYQfmq/OTwXrF5JNdCOA Rv0AnRHcv6bA6B+A+bGl8/Dpb2RDmepr =xUe9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alberto, Please post to the list, rather than writing to me directly. On 9/16/2009 1:19 PM, atroi...@infomedica.it wrote: i' am lookng for a way to resume Tomcat timed-out sessions after a re-logon. So i found this interesting thread where you wrote: If you want users to be able to resume their sessions after a session timeout, you need to provide enough information in the request to either restore the session state or ... That is exactly what i am looking for. Please may you explain me what information i have to provide in the request? Or (better) may you send me a sample code or an url where i can found more documentation about this? This is a question that you will have to answer: what information is absolutely necessary for you to resume a user interaction in-progress? Whatever that is, you'll need to include that information in every single link that a user can click on (or in every form they can submit). There is no tutorial for how to do this, because it's dead simple: just determine what information is required to continue (after a re-login) and ensure that information is available to every request. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqxSfgACgkQ9CaO5/Lv0PDZCACgldPOfYnvnbI38FtQzMKelkUG dOcAn2bD3HjmpGxcLj2EH1YSPES2UzOF =TmrC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, Please keep all discussions on the list. On 2/11/2009 8:08 AM, lync...@gmx.de wrote: First, I did what you suggested and set a Key value pair in the session map. in the login phase im trying to read this value to see if the user is coming from the loginpage. You won't really be able to tell if the user is coming from the login page. The best you can do is to detect that the session is not in a proper state - by checking for some key in the session. I'm just trying to be clear. The problem now seems to be, that i write the session key too late and my lookup happens to early which means that in the lookup moment the key never is set. You have to do your checking in a Filter so that it occurs /before/ the servlet handles the request. Otherwise, you'd have to re-write a LOT of your application to check for proper session state before doing whatever it is your servlet needs to do. We write the session keypair in that moment when we load the userdata which is pretty close after the login form. Exactly where? We try to read the value in the SessionTimeoutFilter. But in this filter, the Key is never set. By the way , we're using JSF(RI) and Orchestra.core v1.2. Maybe this frameworks are involved in our problem im not sure It's possible that the framework is interfering, but unlikely. Can you send the code for your SessionTimeoutFilter as well as the configuration from web.xml for /all/ of your filters? Remember to remove any sensitive information. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmS0qIACgkQ9CaO5/Lv0PDI4QCgtcCRkB/MFRcA0+DOu+66HMxR RlMAn12yFxvfGAURM4IfQ3fVCRtU4EsZ =tRCE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
/filter-mapping-- filter filter-namespringRequestContextFilter/filter-name filter-classorg.springframework.web.filter.RequestContextFilter/filter-class /filter filter filter-nameSessionTimeoutFilter/filter-name filter-classde.we.myproject.util.SessionTimeoutFilter/filter-class /filter filter-mapping filter-namerichfaces/filter-name servlet-nameFaces Servlet/servlet-name dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-namespringRequestContextFilter/filter-name url-pattern/*/url-pattern dispatcherFORWARD/dispatcher dispatcherREQUEST/dispatcher /filter-mapping filter-mapping filter-nameSessionTimeoutFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping listener listener-classcom.sun.faces.config.ConfigureListener/listener-class /listener !-- Using bei Spring -- listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener !-- Orchestra -- listener listener-classorg.springframework.web.context.request.RequestContextListener/listener-class /listener listener listener-classorg.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener/listener-class /listener !--Anfang Session Time Out -- listener listener-classde.we.myproject.util.MySessionListener/listener-class /listener !-- Faces Servlet -- servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet !-- Faces Servlet servlet servlet-nameSourceCodeServlet/servlet-name servlet-class org.apache.myfaces.shared_tomahawk.util.servlet.SourceCodeServlet /servlet-class load-on-startup1/load-on-startup /servlet servlet mapping servlet-mapping servlet-nameSourceCodeServlet/servlet-name url-pattern*.jsf/url-pattern /servlet-mapping -- servlet servlet-nameConfirmServlet/servlet-name servlet-classde.we.myproject.util.UserConfirm/servlet-class /servlet servlet-mapping servlet-nameConfirmServlet/servlet-name url-pattern/confirm/*/url-pattern /servlet-mapping !-- Faces Servlet Mapping -- servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.jsf/url-pattern /servlet-mapping session-config session-timeout1/session-timeout /session-config !--End Session Time Out -- welcome-file-list welcome-file/index.html/welcome-file !-- welcome-file/index.xhtml/welcome-file -- /welcome-file-list error-page exception-typejavax.faces.application.ViewExpiredException/exception-type location/login_error.html/location /error-page !-- orchestraFilter -- filter filter-nameorchestraFilter/filter-name filter-classorg.apache.myfaces.orchestra.conversation.jsf.filter.OrchestraServletFilter /filter-class init-param param-nameserializeRequests/param-name param-valuetrue/param-value /init-param /filter filter-mapping filter-nameorchestraFilter/filter-name url-pattern*.jsf/url-pattern dispatcherFORWARD/dispatcher dispatcherREQUEST/dispatcher /filter-mapping !-- test -- security-constraint web-resource-collection web-resource-nameGeschuetzter Bereich/web-resource-name url-pattern/pages/*/url-pattern /web-resource-collection auth-constraint role-namekunde/role-name role-namepremiumkunde/role-name role-namesuperuser/role-name role-nameuser/role-name role-namepremiumuser/role-name role-nameadmin/role-name /auth-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.jsf/form-login-page form-error-page/login_error.jsf/form-error-page /form-login-config /login-config security-role role-namekunde/role-name /security-role security-role role-namepremiumkunde/role-name /security-role security-role role-namesuperuser/role-name /security-role security-role role-nameguest/role-name /security-role security-role role-namepremiumGuest/role-name /security-role security-role role-nameadmin/role-name !--user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint-- /security-role /web-app thank again for reading all the stuff chris , cheers filip -- View this message in context: http://www.nabble.com/Tomcat-Realm-Auto-Relogin-after-Session-Timeout-Problem-tp21938671p21956226.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
To the OP: If you can hold it for a while: I'll be on the Hackation during the ApacheConEurope in March and will provide a small piece of code there, whis is basically a LoginValve doing the following: - You can customize the url Tomcat shall call if authentication times out - Since a valve can be used both on server and context-level, you can use it quite flexible. However, will still have to test it and write some docs for it, but that should be done by then. The most complicated thing is to set up a working environment for the Tomcat-sources in Eclipse *sic* If your request is all that urgent, I might send you a working copy beforehand. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, On 2/11/2009 9:32 AM, lynckmeister wrote: Exactly where? Im writing this in a Sigelton bean wich is initialized via spring with the postconstruct paramenter. it seems that this is to late, what do you suggest ? maybe a special filter would be a better place? like the following : @PostConstruct public void SNUserSingletonInit() { session.setAttribute(ISVALID,test); } Hmm... I'm a little out of my league, here. I don't know a thing about orchestra, and your stack trace tells me nothing since there are no servlet API classes in there. I honestly don't have any idea where your code is being called from. Can you give me more of the stack trace? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmS74IACgkQ9CaO5/Lv0PDn2QCgk5AKe1vyvarJxuoIk/n3sE3P jxIAnjJ1bBhR+8bYvuc9XwZEg3teOh5i =qqtc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
FacesServlet.service(ServletRequest, ServletResponse) line: 245 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 290 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 ConfigurableXMLFilter(BaseXMLFilter).doXmlFilter(FilterChain, HttpServletRequest, HttpServletResponse) line: 177 Filter(BaseFilter).handleRequest(HttpServletRequest, HttpServletResponse, FilterChain) line: 267 Filter(BaseFilter).processUploadsAndHandleRequest(HttpServletRequest, HttpServletResponse, FilterChain) line: 380 Filter(BaseFilter).doFilter(ServletRequest, ServletResponse, FilterChain) line: 507 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 235 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 OrchestraServletFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 77 CompoundFilter$1.doFilter(ServletRequest, ServletResponse) line: 58 _NullFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 45 OrchestraServletFilter(CompoundFilter).doFilter(ServletRequest, ServletResponse, FilterChain) line: 63 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 235 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 SessionTimeoutFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 76 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 235 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 RequestContextFilter.doFilterInternal(HttpServletRequest, HttpServletResponse, FilterChain) line: 83 RequestContextFilter(OncePerRequestFilter).doFilter(ServletRequest, ServletResponse, FilterChain) line: 76 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 235 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 StandardWrapperValve.invoke(Request, Response) line: 233 StandardContextValve.invoke(Request, Response) line: 175 FormAuthenticator(AuthenticatorBase).invoke(Request, Response) line: 525 StandardHostValve.invoke(Request, Response) line: 128 ErrorReportValve.invoke(Request, Response) line: 102 StandardEngineValve.invoke(Request, Response) line: 109 CoyoteAdapter.service(Request, Response) line: 286 Http11Processor.process(Socket) line: 844 Http11Protocol$Http11ConnectionHandler.process(Socket) line: 583 JIoEndpoint$Worker.run() line: 447 Thread.run() line: 619 -- View this message in context: http://www.nabble.com/Tomcat-Realm-Auto-Relogin-after-Session-Timeout-Problem-tp21938671p21957555.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Hi Gregor, I didnt get it. Your writing a peace of code wich lets me custmize the url or page wich is called if a sessiontimeout occurs? that would be interessting, but I cant believe that there is no common way to handle such a problem ... what do i afford to use it? I need to recompile the tomcat? im not sure if I can to that on the final productive system... Gregor Schneider wrote: To the OP: If you can hold it for a while: I'll be on the Hackation during the ApacheConEurope in March and will provide a small piece of code there, whis is basically a LoginValve doing the following: - You can customize the url Tomcat shall call if authentication times out - Since a valve can be used both on server and context-level, you can use it quite flexible. However, will still have to test it and write some docs for it, but that should be done by then. The most complicated thing is to set up a working environment for the Tomcat-sources in Eclipse *sic* If your request is all that urgent, I might send you a working copy beforehand. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://www.nabble.com/Tomcat-Realm-Auto-Relogin-after-Session-Timeout-Problem-tp21938671p21957617.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
On Wed, Feb 11, 2009 at 4:43 PM, lynckmeister lync...@gmx.de wrote: Hi Gregor, I didnt get it. Your writing a peace of code wich lets me custmize the url or page wich is called if a sessiontimeout occurs? Nope. What the Valve does, ist the following: If a session times out, usually nothing is happening. However, when requesting some content of the protected site *after* the session times out, Tomcat usually does the following: - store the original request - call the defined-login-screen via j_security - if authentication is ok, procede to the url contained in the original request It's obvious that there are some scenarios where this behaviour is causing problems, i.e. url-selections via a javascript-menue, framed sites etc. However, when using the valve, you can specify the url to which should be forwarded *after* positive authentication, i.e. index.html. Therefore, I figure that such a valve might be a perfect solution for your problem. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip, On 2/11/2009 10:40 AM, lynckmeister wrote: SessionScope.get(String, ObjectFactory) line: 90 DefaultListableBeanFactory(AbstractBeanFactory).doGetBean(String, Class, Object[], boolean) line: 298 DefaultListableBeanFactory(AbstractBeanFactory).getBean(String, Class, Object[]) line: 185 DefaultListableBeanFactory(AbstractBeanFactory).getBean(String) line: 164 XmlWebApplicationContext(AbstractApplicationContext).getBean(String) line: 881 DelegatingVariableResolver.resolveSpringBean(FacesContext, String) line: 142 DelegatingVariableResolver.resolveVariable(FacesContext, String) line: 109 VariableResolverChainWrapper.getValue(ELContext, Object, Object) line: 100 FacesCompositeELResolver(CompositeELResolver).getValue(ELContext, Object, Object) line: 53 FacesCompositeELResolver.getValue(ELContext, Object, Object) line: 64 AstIdentifier.getValue(EvaluationContext) line: 61 AstValue.getValue(EvaluationContext) line: 103 ValueExpressionImpl.getValue(ELContext) line: 186 TagValueExpression.getValue(ELContext) line: 71 HtmlInputText(UIOutput).getValue() line: 173 TextRenderer(HtmlBasicInputRenderer).getValue(UIComponent) line: 189 These lines seem to me to be running in the view phase, which should be after the request has been handled by the controller (i.e. the logic). Try writing a javax.servlet.Filter and having it run /before/ the OrchestraFilter in your filter chain (that is, put it in web.xml before the existing Filter). You should be able to pre-process your request/session in this way. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmS//gACgkQ9CaO5/Lv0PDaKACeOYou60WgvuY4X934rl3+9EOg jWkAnikNqsjw8TNyqj1pQklBXWpO6tVf =fieW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregor, On 2/11/2009 10:17 AM, Gregor Schneider wrote: I'll be on the Hackation during the ApacheConEurope in March and will provide a small piece of code there, whis is basically a LoginValve doing the following: - You can customize the url Tomcat shall call if authentication times out - Since a valve can be used both on server and context-level, you can use it quite flexible. Note that securityfilter implements the feature you describe, though it is separate from Tomcat's container-managed authentication and authorization. It is also implemented as a filter, so it can be deployed on servers other than Tomcat. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmTAjsACgkQ9CaO5/Lv0PDPwQCbBAO+VLCT+fx3V7d5yaKr2E5f G5IAniQzP8Fnr1hGfKyCfRnboLZYoEsI =N2p/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Chris, On Wed, Feb 11, 2009 at 5:52 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Note that securityfilter implements the feature you describe, though it is separate from Tomcat's container-managed authentication and authorization. It is also implemented as a filter, so it can be deployed on servers other than Tomcat. I very well know this, however, SecurityFilter for me (or our specific situation here) has a showstopper since it does not support Tomcat's SingleSignOn-feature, if I'm not mistaken. If I remember correctly, you told me once that this might be implemented in one of the future releases - right? Other than that, it's a great piece of software. This little valve, however, has the disadvantage that it will work with Tomcat only, OTOH it's pretty damn small, easy to install to configure. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregor, On 2/11/2009 12:13 PM, Gregor Schneider wrote: I very well know this, however, SecurityFilter for me (or our specific situation here) has a showstopper since it does not support Tomcat's SingleSignOn-feature, if I'm not mistaken. If I remember correctly, you told me once that this might be implemented in one of the future releases - right? Maybe. The problem is that sessions are aap-specific, and securityfilter would have to resort to other mechanisms to provide that feature. I have some devious ideas that might work, though ;) Other than that, it's a great piece of software. Thanks. I mostly inherited it, so I can't take too much credit. This little valve, however, has the disadvantage that it will work with Tomcat only, OTOH it's pretty damn small, easy to install to configure. ...and really, who would use anything but Tomcat, anyway? ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmTSC8ACgkQ9CaO5/Lv0PCL0gCeKyot9vHPUPc8Tv3JxsWuC8JT ZoIAn3YthZRXSTRrek3rvAt8EeMcnXYG =+Rdy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Realm Auto-Relogin after Session-Timeout Problem
Dear Forum , i have the problem that if my session timeouts i 've been redirected to the loginpage ( from the secured area). If i relogin in i get some null-pointer exceptions in my application ( first the orchestra framework has a problem ) i investigated , and it seems to be the problem , that the realm stores the request of the original call. if the user relogons now, the first request seems to be substituted. in my sessionfilter , im trying to check if the session is invalid, but its not, b/c there is allready a new valid session after login. Is there a possibility to affect this behave, fe that the realm just leds me to the login page and nothing more ? thanks a lot for help !! Filip -- View this message in context: http://www.nabble.com/Tomcat-Realm-Auto-Relogin-after-Session-Timeout-Problem-tp21938671p21938671.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lynckmeister, On 2/10/2009 12:34 PM, lynckmeister wrote: i have the problem that if my session timeouts i 've been redirected to the loginpage ( from the secured area). If i relogin in i get some null-pointer exceptions in my application ( first the orchestra framework has a problem ) This is not surprising, as your session state has most likely been reset. If you want users to be able to resume their sessions after a session timeout, you need to provide enough information in the request to either restore the session state, or to indicate to the user that they need to start their process over after the re-login. i investigated , and it seems to be the problem , that the realm stores the request of the original call. if the user relogons now, the first request seems to be substituted. Correct. This follows section 12.5.3 of the servlet specification: When a user attempts to access a protected web resource, the container checks the user’s authentication. If the user is authenticated and possesses authority to access the resource, the requested web resource is activated and a reference to it is returned. If the user is not authenticated, all of the following steps occur: 1. The login form associated with the security constraint is sent to the client and the URL path triggering the authentication is stored by the container. 2. The user is asked to fill out the form, including the username and password fields. 3. The client posts the form back to the server. 4. The container attempts to authenticate the user using the information from the form. 5. If authentication fails, the error page is returned using either a forward or a re-direct, and the status code of the response is set to 200. 6. If authentication succeeds, the authenticated user’s principal is checked to see if it is in an authorized role for accessing the resource. 7. If the user is authorized, the client is redirected to the resource using the stored URL path. in my sessionfilter , im trying to check if the session is invalid, but its not, b/c there is already a new valid session after login. Instead of checking for a non-null session, maybe you should check for an object that you put in there -- something like SESSION_IS_VALID. Tomcat will definitely create the new session for you, but it won't store any attributes in there, so you can always add your own. This is what we do in our application. On each request, we look for an object in the session attributes called USER. If it's in there, we do nothing and let the request proceed as usual. If it's not in there, we perform a formal login, get user preferences from the database, etc. and stuff them into the session. Then, we allow the request to proceed as usual. Is there a possibility to affect this behavior, of that the realm just leads me to the login page and nothing more ? See above. Maybe that technique will work for you. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmR44YACgkQ9CaO5/Lv0PBK0ACffke/TykyTmUW36eRXSziSDcb fUwAn1tpn5WlYsgM1T7JT6yJBARzqXF1 =B+0O -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org