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
dear christoph, hope that this is not private now , i was sure, that i sent
the last one also to the list... anyway ...
again thanks for you help ...
i copied now all the gode as desired and hope that this will help ;)
ou 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.
no i dont case all i want is to relogin without after crash if a timeout
happens...
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.
yes that sounds logical to me but were is the right point ...;)
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);
}
to give you an idea , where in the activity chain we are I send you the
callstack wich is shown if I set a breakboint the the codeline wich setts
the session-key:
SNUserSessionUtil.SNUserSingletonInit() line: 53
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(Object) line:
297
InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(Object,
String) line: 250
CommonAnnotationBeanPostProcessor(InitDestroyAnnotationBeanPostProcessor).postProcessBeforeInitialization(Object,
String) line: 144
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).applyBeanPostProcessorsBeforeInitialization(Object,
String) line: 350
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).initializeBean(String,
Object, RootBeanDefinition) line: 1329
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).doCreateBean(String,
RootBeanDefinition, Object[]) line: 471
AbstractAutowireCapableBeanFactory$1.run() line: 409
AccessController.doPrivileged(PrivilegedActionT, AccessControlContext)
line: not available [native method]
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).createBean(String,
RootBeanDefinition, Object[]) line: 380
AbstractBeanFactory$2.getObject() line: 302
SessionScope(AbstractRequestAttributesScope).get(String, ObjectFactory)
line: 43
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
DefaultListableBeanFactory.findAutowireCandidates(String, Class,
DependencyDescriptor) line: 671
DefaultListableBeanFactory.resolveDependency(DependencyDescriptor, String,
Set, TypeConverter) line: 610
AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(Object,
String, PropertyValues) line: 412
InjectionMetadata.injectFields(Object, String) line: 105
AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(Object,
String) line: 240
and so on...
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.
Ok here comes the the code please have a look at the incode comments...
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
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
Can you give me more of the stack trace? Sure, here we go : SNUserSessionUtil.SNUserSingletonInit() line: 53 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(Object) line: 297 InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(Object, String) line: 250 CommonAnnotationBeanPostProcessor(InitDestroyAnnotationBeanPostProcessor).postProcessBeforeInitialization(Object, String) line: 144 DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).applyBeanPostProcessorsBeforeInitialization(Object, String) line: 350 DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).initializeBean(String, Object, RootBeanDefinition) line: 1329 DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).doCreateBean(String, RootBeanDefinition, Object[]) line: 471 AbstractAutowireCapableBeanFactory$1.run() line: 409 AccessController.doPrivileged(PrivilegedActionT, AccessControlContext) line: not available [native method] DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).createBean(String, RootBeanDefinition, Object[]) line: 380 AbstractBeanFactory$2.getObject() line: 302 SessionScope(AbstractRequestAttributesScope).get(String, ObjectFactory) line: 43 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 DefaultListableBeanFactory.findAutowireCandidates(String, Class, DependencyDescriptor) line: 671 DefaultListableBeanFactory.resolveDependency(DependencyDescriptor, String, Set, TypeConverter) line: 610 AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(Object, String, PropertyValues) line: 412 InjectionMetadata.injectFields(Object, String) line: 105 AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(Object, String) line: 240 DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).populateBean(String, AbstractBeanDefinition, BeanWrapper) line: 957 DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).doCreateBean(String, RootBeanDefinition, Object[]) line: 470 AbstractAutowireCapableBeanFactory$1.run() line: 409 AccessController.doPrivileged(PrivilegedActionT, AccessControlContext) line: not available [native method] DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).createBean(String, RootBeanDefinition, Object[]) line: 380 AbstractBeanFactory$2.getObject() line: 302 SessionScope(AbstractRequestAttributesScope).get(String, ObjectFactory) line: 43 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 TextRenderer(HtmlBasicRenderer).getCurrentValue(FacesContext, UIComponent) line: 320 TextRenderer(HtmlBasicRenderer).encodeEnd(FacesContext, UIComponent) line: 200 HtmlInputText(UIComponentBase).encodeEnd(FacesContext) line: 829 HtmlInputText(UIComponent).encodeAll(FacesContext) line: 894 FormRenderer(Renderer).encodeChildren(FacesContext, UIComponent) line: 137 HtmlForm(UIComponentBase).encodeChildren(FacesContext) line: 810 HtmlForm(UIComponent).encodeAll(FacesContext) line: 884 AjaxViewRoot(UIComponent).encodeAll(FacesContext) line: 890 FaceletViewHandler.renderView(FacesContext, UIViewRoot) line: 592 AjaxViewHandler(ViewHandlerWrapper).renderView(FacesContext, UIViewRoot) line: 108 AjaxViewHandler.renderView(FacesContext, UIViewRoot) line: 196 RenderResponsePhase.execute(FacesContext) line: 106 LifecycleImpl.phase(PhaseId, Phase, FacesContext) line: 248 LifecycleImpl.render(FacesContext) line: 144
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
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
