You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by lynckmeister <ly...@gmx.de> on 2009/02/10 18:34:47 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Gregor Schneider <rc...@googlemail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Gregor Schneider <rc...@googlemail.com>.
On Wed, Feb 11, 2009 at 4:43 PM, lynckmeister <ly...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by lynckmeister <ly...@gmx.de>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Gregor Schneider <rc...@googlemail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by lynckmeister <ly...@gmx.de>.
>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(PrivilegedAction<T>, 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(PrivilegedAction<T>, 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
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat Realm Auto-Relogin after Session-Timeout Problem
Posted by lynckmeister <ly...@gmx.de>.
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(PrivilegedAction<T>, 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 (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);
httpServletResponse.sendRedirect(timeoutUrl);
return;
}
}
}
filterChain.doFilter(request, response);
System.out.println("test Request");
}
/**
*
* session shouldn't be checked for some pages. For example: for timeout
* page.. Since we're redirecting to timeout page from this filter, if we
* don't disable session control for it, filter will again redirect to it
* and this will be result with an infinite loop...
*/
private boolean isSessionControlRequiredForThisResource(
HttpServletRequest httpServletRequest) {
String requestPath = httpServletRequest.getRequestURI();
boolean controlRequired =
!StringUtils.contains(requestPath,getTimeoutPage());
return controlRequired;
}
public void destroy() {
}
public String getTimeoutPage() {
return timeoutPage;
}
public void setTimeoutPage(String timeoutPage) {
this.timeoutPage = timeoutPage;
}
the web xml :
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<!-- Use for facelets -->
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.xhtml</param-value>
</context-param>
<!-- Special Debug Output for Development -->
<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>
<!-- -->
<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>
<!-- context-param>
<param-name>facelets.BUFFER_SIZE</param-name>
<param-value>10000</param-value>
</context-param -->
<context-param>
<param-name>facelets.REFRESH_PERIOD</param-name>
<param-value>0</param-value>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
<context-param>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>/WEB-INF/faces-config.xml</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.verifyObjects</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING_DISPATCH_EVERY_TIME</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>facelets.LIBRARIES</param-name>
<param-value>/WEB-INF/myproject.taglib.xml;</param-value>
</context-param>
<!-- Vladi -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<!-- filter>
<filter-name>HibernateFilter</filter-name>
<filter-class>de.we.myproject.hibernate.HibernateFilter</filter-class>
</filter
Filter zur Überprufung des Logins
filter>
<filter-name>myproject-Auth-Filter</filter-name>
<filter-class>de.we.myproject.Util.AuthFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>myproject-Auth-Filter</filter-name>
<url-pattern>/pages/*</url-pattern>
</filter-mapping
filter-mapping>
<filter-name>HibernateFilter</filter-name>
<url-pattern>*.jsf</url-pattern>
</filter-mapping
Using bei Richfaces -->
<context-param>
<param-name>org.richfaces.SKIN</param-name>
<param-value>myproject</param-value>
</context-param>
<!--Richfaces has a few parsers onboard. The default one is based on Tidy,
but it is quite slow.
The Neko parser is faster and can be used by setting the following
context-param’
Fast Filter which is based on nekko parser requires nekkohtml.jar and
xersesimpl.jar in your classpath. As this filter wasn't default for A4j and
later RF -
these jars arent included to distribution. Download it and put in your
classpath.-->
<context-param>
<param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
<param-value>TIDY,NEKO</param-value>
</context-param>
<!-- param-value>NEKO</param-value -->
<context-param>
<param-name>org.ajax4jsf.xmlparser.TIDY</param-name>
<param-value>/pages/announcement/notif_1.xhtml,
/pages/announcement/notif_1_search.xhtml,
/pages/announcement/mynotif.xhtml,
/pages/gatgets/show_gatgets.xhtml,
/pages/gatgets/my_gatgets.xhtml,
/pages/profile/profile_results.xhtml,
/pages/profile/profile_results_2.xhtml,
/pages/profile/show_profile_friends.xhtml,
/pages/profile/show_profile_trophies.xhtml,
/pages/profile/show_profile_groups.xhtml,
/pages/profile/show_profile_photoAlbums.xhtml,
/pages/myNetwork/addressbook_1.xhtml,
/pages/myNetwork/1_search.xhtml,
/pages/myNetwork/addressbook_2.xhtml,
/pages/myNetwork/addressbook_3.xhtml,
/pages/groups/searchgroup.xhtml,
/pages/groups/mygroupmessage.xhtml,
/pages/groups/mygroup.xhtml,
/pages/groups/updateGroup1.xhtml,
/pages/fotoAlbum/myPhotoAlbum.xhtml,
/pages/fotoAlbum/photoAlbums.xhtml,
/pages/messages/posteingang.xhtml,
/pages/messages/postausgang.xhtml,
/pages/appointment/appointment.xhtml,
/pages/appointment/myAppointment.xhtml</param-value>
</context-param>
<context-param>
<param-name>org.ajax4jsf.xmlparser.NEKO</param-name>
<param-value>.*\..*</param-value>
</context-param>
<!-- The following declaration allows to load only one integrated style
sheet file.
The integrated style sheet contains style for all shipped components.
The skinnability feature still works.
The "DEFAULT" value is a classical on-demand variant.
The "NONE" stops loading the styles at all.
The earlier introduced plain skin resets all color and font parameters
to null.
The "NONE" value for org.richfaces.LoadStyleStrategy means that
predefined
styles for RichFaces are not used. -->
<context-param>
<param-name>org.richfaces.LoadScriptStrategy</param-name>
<param-value>none</param-value>
</context-param>
<!-- Orchastra Optional
filter>
<filter-name>frameworkAdapterFilter</filter-name>
<filter-class>org.apache.myfaces.orchestra.frameworkAdapter.basic.BasicFrameworkAdapterFilter</filter-class>
</filter>
<filter>
<filter-name>requestParameterFilter</filter-name>
<filter-class>org.apache.myfaces.orchestra.requestParameterProvider.RequestParameterServletFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>frameworkAdapterFilter</filter-name>
<url-pattern>*.jsf</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>requestParameterFilter</filter-name>
<url-pattern>*.jsf</url-pattern>
</filter-mapping -->
<context-param>
<param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
<param-value>com.sun.facelets.FaceletViewHandler</param-value>
</context-param>
<filter>
<display-name>RichFaces Filter</display-name>
<filter-name>richfaces</filter-name>
<filter-class>org.ajax4jsf.Filter</filter-class>
<init-param>
<param-name>forceparser</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>enable-cache</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>maxRequestSize</param-name>
<param-value>1250000</param-value>
</init-param>
<init-param>
<param-name>createTempFiles</param-name>
<param-value>false</param-value>
</init-param>
</filter>
<!-- filter-mapping>
<filter-name>SessionTimeoutFilter</filter-name>
<url-pattern>*.jsf</url-pattern>
</filter-mapping-->
<filter>
<filter-name>springRequestContextFilter</filter-name>
<filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
</filter>
<filter>
<filter-name>SessionTimeoutFilter</filter-name>
<filter-class>de.we.myproject.util.SessionTimeoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>richfaces</filter-name>
<servlet-name>Faces Servlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>springRequestContextFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>SessionTimeoutFilter</filter-name>
<url-pattern>*.jsf</url-pattern>
</filter-mapping>
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
<!-- Using bei Spring -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- Orchestra -->
<listener>
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
<listener>
<listener-class>org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener</listener-class>
</listener>
<!--Anfang Session Time Out -->
<listener>
<listener-class>de.we.myproject.util.MySessionListener</listener-class>
</listener>
<!-- Faces Servlet -->
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Faces Servlet
servlet>
<servlet-name>SourceCodeServlet</servlet-name>
<servlet-class>
org.apache.myfaces.shared_tomahawk.util.servlet.SourceCodeServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet
servlet mapping
servlet-mapping>
<servlet-name>SourceCodeServlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping -->
<servlet>
<servlet-name>ConfirmServlet</servlet-name>
<servlet-class>de.we.myproject.util.UserConfirm</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ConfirmServlet</servlet-name>
<url-pattern>/confirm/*</url-pattern>
</servlet-mapping>
<!-- Faces Servlet Mapping -->
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>1</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-type>javax.faces.application.ViewExpiredException</exception-type>
<location>/login_error.html</location>
</error-page>
<!-- orchestraFilter -->
<filter>
<filter-name>orchestraFilter</filter-name>
<filter-class>org.apache.myfaces.orchestra.conversation.jsf.filter.OrchestraServletFilter
</filter-class>
<init-param>
<param-name>serializeRequests</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>orchestraFilter</filter-name>
<url-pattern>*.jsf</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<!-- test -->
<security-constraint>
<web-resource-collection>
<web-resource-name>Geschuetzter Bereich</web-resource-name>
<url-pattern>/pages/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>kunde</role-name>
<role-name>premiumkunde</role-name>
<role-name>superuser</role-name>
<role-name>user</role-name>
<role-name>premiumuser</role-name>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</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-name>kunde</role-name>
</security-role>
<security-role>
<role-name>premiumkunde</role-name>
</security-role>
<security-role>
<role-name>superuser</role-name>
</security-role>
<security-role>
<role-name>guest</role-name>
</security-role>
<security-role>
<role-name>premiumGuest</role-name>
</security-role>
<security-role>
<role-name>admin</role-name>
<!--user-data-constraint>
<transport-guarantee>CONFIDENTIAL</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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org