Securityfilter does not manage sessions or URL rewriting. Whatever is happening is being done by your servlet container.
Often, this happens because your JSPs have not had "session=false" declared in your @page directive. If you don't do this, your container will often automatically create a session for every visitor, even if you don't have any authentication or login or anything like that.
If you have further questions, I would recommend asking your app server vendor.
Hope that helps,
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Chris. I thought it might be security filter because of the remember me code, but I do have that turned off at the moment. I did not realize Tomcat 6.18 would always cause a sessionid to be on. I use it with Struts and Velocity -- a bit confusing trying to figure out where it could be occurring.
Thank you for your help though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I always recommend to folks who ask on the Tomcat mailing list where sessions are being created to write a simple HttpSessionListener that looks like this:
public void sessionCreated(HttpSessionEvent evt)
{
System.out.println("Session created!!");
new Throwable("Session Creation Backtrace").printStackTrace();
}
This will show you where all sessions are being created if you install it properly.
Hope that helps,
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am thinking it may not be fixed in the trunk. After downloading the code, I used a listener to create an exception when a session was created. It ended up having an exception in SecurityFilter as shown below. I have to go right now, but in looking at the code in that file I did see this, though it may not be the exact cause. Have to look later.
public static void saveRequestInformation(HttpServletRequest request) {
HttpSession session = request.getSession();
session.setAttribute(SecurityFilter.SAVED_REQUEST_URL, getSaveableURL(request));
session.setAttribute(SecurityFilter.SAVED_REQUEST, new SavedRequest(request));
}
SEVERE: Session event listener threw exception
com.common.error.ApplicationException: SESSION CREATED.
at com.commonmvc.listener.SessionListenerLogger.sessionCreated(SessionListenerLogger.java:114)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:829)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:844)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:224)
at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146)
at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:124)
at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:107)
at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:63)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:53)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:231)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.commonmvc.filter.session.UrlSessionFilter.doFilter(UrlSessionFilter.java:87)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.commonmvc.filter.encoding.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The stack trace shown does not include the method whose code you posted. Was there more of the stack trace?
The saveRequestInformation method will be called when a request comes into your webapp and sf intercepts it, determines that the user has not yet been authenticated, and needs to perform authentication. The original request is stored in the session (which must exist, hence the call to getSession /without/ passing "false") and then authentication occurs. The saved request is played-back after successful authentication.
I think your session is being created elsewhere, though:
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:224)
at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146)
at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:124)
This indicates that the JSP itself is requesting a session during page initialization. Have you set session="false" in your @page directive? If not, your JSPs will automatically create sessions for you.
We find this on the Tomcat mailing list all the time: sessions are being created and the JSP authors don't know where they're coming from.
JSP specification 2.1 section 1.10.1 states of the "session" attribute for the @page directive:
"
Indicates that the page requires participation in an (HTTP)
session.
If true then the implicit script language variable named ses-
sion of type javax.servlet.http.HttpSession references the
current/new session for the page.
If false then the page does not participate in a session; the
session implicit variable is unavailable, and any reference to
it within the body of the JSP page is illegal and shall result in
a fatal translation error.
Default is true.
"
So there you have it: you'll need to set session="false" in your JSPs to avoid the implicit session creation.
Hope that helps,
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that SecurityFilter will create a session when the user requests a secured page:
1. user requests secured page
2. security filter creates a session (to save the URL the user was trying to reach)
3. login screen appears
...
I just want to make it clear that security filter does create the session before the user logs in, when you consider the sequence in detail. This is the correct and expected behavior. Security filter should NOT create a session before a secure page is requested.
Since saveRequestInformation() is in the stack trace, and saveRequestInformation() should only be called when a secure page is requested, this makes me think that security filter is behaving properly with respect to creating a session. A secured resource is being requested, so security filter created a session. Note that this can happen in the obvious way -- the user actually requested a secured page. But it can also happen in more subtle ways -- a bug in an img tag with the src set to a secured url, an overly-inclusive url-pattern in the security filter config, etc. -- the user generally won't see the login page with bugs of this nature.
Can you describe in a little more detail the scenario where security filter is creating a session prematurely?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 1. user requests secured page
> 2. security filter creates a session (to save the URL the user was trying to reach)
> 3. login screen appears
I'd like to point out that this is how most application servers work when using form-based logins: their form authenticators will store the saved request in the session. Although the servlet specification does not mandate that the session be used for storage of the saved URL (or even that a session must be created prior to login), it is the most obvious strategy for performing this task.
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We use Tomcat/Velocity/Tiles/Struts so no JSPs, but your point is understood. We went through all of our code and we are not calling a getSession(true) type of thing until after the user is logged in. We logged our filter start/ends. There was no session in the results until this exception in Security filter which showed the exception at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:231). Intentionally I placed this filter in between two other filters that I could log easily. It never got to the 3rd filter.
The SessionListenerLogger just is a session listener kicking off the exception above when session is created, similar to what was posted above.
Thank you. We will look into this more here. Maybe Tomcat is creating it somehow internally. There is the ability to turn off cookie use in Tomcat in its Context configuration, but we just would want no sessions until the user is logged in. We never had to worry about this before, but now we are concerned about search engines being hard on our site due to jsessionid showing up in their URLs.
Likely this is something we are doing, but your wisdom is appreciated very much.
JohnE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Realization strikes. We do have one JSP and only one JSP -- a basic index.jsp that just forwards to our real home page link. Will try to see if the session=false will fix this issue later. The odd thing is where the exception occurred though. It occurred during the SecurityFilter.java:231 as the second of three filters, with the third filter not being reached. Not confident the fix above is the only reason, but at least it is a good chance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to say thank you. It seems that there are many other places where session is being created without my wishing it. So far, using something similar to your HttpSessionListener, I have been able to track down some issues. None of them so far are in my code, but rather in things like Struts. Found that in Struts 1.2.* that it puts a "locale" into the session automatically unless you turn it off in the struts-config file using session=false there.
Have another case of session to try to work out tonight along similar lines that seems to occur as part of Struts, Tiles, or Tomcat.
Seems that auto-session usage is a huge mistake as it automatically places a framework in jeopardy with SEO lowering their ability to compete. The "end result" should be the first thing on a framework's place, not technology bells and whistles.
Will write back once figure out other issues so that other people have this information.
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You might want to read this page (http://randomcoder.com/articles/jsessionid-considered-harmful) and some of its related material. These guys offer some techniques to help avoid the session id being included in the URLs for search engines. Of course, reducing the number of sessions created is always good if you don't need to be creating them in the first place.
Good luck,
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Agree, but it seems that Apache Tiles pre-2.0.5 creates them automatically unconfigurably. Was able to remove them out of Struts, but...it is difficult to get away from forced use of sessions when I would think it should be the default until perhaps authenticated.
Still trying to think of a way. Thank you for that link on "jsessionid-considered-harmful" the URL Christopher. It may be something I will do, but it also seems to prohibit the use of any users without cookies.
Google has said session id is not a concern nor is query strings in general, but based on the links I am seeing people save and such, I disagree and it is good to have an option. There are some URLs with jsessionid pointing to our site.
This is a challenge to figure yet a new challenge. There seems to be no clear solution except not having any of your applications use sessions in the first place. If only that were possible at the moment...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you choose to implement a filter that suppresses url-encoded session ids, you can always check the User-Agent string from the HTTP request headers. That way, you can suppress url-encoded session ids (or the session entirely, actually) only for clients such as "google" or whatever you want to use.
You can still service regular users whose web browsers supply a legitimate User-Agent string (and pretty much all do).
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any reason why session id would be being tagged to the end of many of our URLs when there has been no log-in as of yet? Any bug/remedy?
John
Securityfilter does not manage sessions or URL rewriting. Whatever is happening is being done by your servlet container.
Often, this happens because your JSPs have not had "session=false" declared in your @page directive. If you don't do this, your container will often automatically create a session for every visitor, even if you don't have any authentication or login or anything like that.
If you have further questions, I would recommend asking your app server vendor.
Hope that helps,
-chris
Thanks Chris. I thought it might be security filter because of the remember me code, but I do have that turned off at the moment. I did not realize Tomcat 6.18 would always cause a sessionid to be on. I use it with Struts and Velocity -- a bit confusing trying to figure out where it could be occurring.
Thank you for your help though.
John,
I always recommend to folks who ask on the Tomcat mailing list where sessions are being created to write a simple HttpSessionListener that looks like this:
public void sessionCreated(HttpSessionEvent evt)
{
System.out.println("Session created!!");
new Throwable("Session Creation Backtrace").printStackTrace();
}
This will show you where all sessions are being created if you install it properly.
Hope that helps,
-chris
Cool -- I like this technique. :-)
-Max
John,
There was a bug in securityfilter that would create sessions when you didn't need one:
https://sourceforge.net/tracker/index.php?func=detail&aid=1056920&group_id=59484&atid=491164
The fix has not been released yet, AFAIK, since it was fixed in 2006, after the latest release of securityfilter (2.0 in 2004).
You could build from the latest sources in CVS for the quickest fix.
It sounds like we should do a release, too.
-Max
I built from CVS and will give the new version a shot. It seems to work locally. Thank you both.
I am thinking it may not be fixed in the trunk. After downloading the code, I used a listener to create an exception when a session was created. It ended up having an exception in SecurityFilter as shown below. I have to go right now, but in looking at the code in that file I did see this, though it may not be the exact cause. Have to look later.
public static void saveRequestInformation(HttpServletRequest request) {
HttpSession session = request.getSession();
session.setAttribute(SecurityFilter.SAVED_REQUEST_URL, getSaveableURL(request));
session.setAttribute(SecurityFilter.SAVED_REQUEST, new SavedRequest(request));
}
SEVERE: Session event listener threw exception
com.common.error.ApplicationException: SESSION CREATED.
at com.commonmvc.listener.SessionListenerLogger.sessionCreated(SessionListenerLogger.java:114)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:829)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:844)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:224)
at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146)
at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:124)
at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:107)
at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:63)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:53)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:231)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.commonmvc.filter.session.UrlSessionFilter.doFilter(UrlSessionFilter.java:87)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.commonmvc.filter.encoding.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
John,
The stack trace shown does not include the method whose code you posted. Was there more of the stack trace?
The saveRequestInformation method will be called when a request comes into your webapp and sf intercepts it, determines that the user has not yet been authenticated, and needs to perform authentication. The original request is stored in the session (which must exist, hence the call to getSession /without/ passing "false") and then authentication occurs. The saved request is played-back after successful authentication.
I think your session is being created elsewhere, though:
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:224)
at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146)
at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:124)
This indicates that the JSP itself is requesting a session during page initialization. Have you set session="false" in your @page directive? If not, your JSPs will automatically create sessions for you.
We find this on the Tomcat mailing list all the time: sessions are being created and the JSP authors don't know where they're coming from.
JSP specification 2.1 section 1.10.1 states of the "session" attribute for the @page directive:
"
Indicates that the page requires participation in an (HTTP)
session.
If true then the implicit script language variable named ses-
sion of type javax.servlet.http.HttpSession references the
current/new session for the page.
If false then the page does not participate in a session; the
session implicit variable is unavailable, and any reference to
it within the body of the JSP page is illegal and shall result in
a fatal translation error.
Default is true.
"
So there you have it: you'll need to set session="false" in your JSPs to avoid the implicit session creation.
Hope that helps,
-chris
Note that SecurityFilter will create a session when the user requests a secured page:
1. user requests secured page
2. security filter creates a session (to save the URL the user was trying to reach)
3. login screen appears
...
I just want to make it clear that security filter does create the session before the user logs in, when you consider the sequence in detail. This is the correct and expected behavior. Security filter should NOT create a session before a secure page is requested.
Since saveRequestInformation() is in the stack trace, and saveRequestInformation() should only be called when a secure page is requested, this makes me think that security filter is behaving properly with respect to creating a session. A secured resource is being requested, so security filter created a session. Note that this can happen in the obvious way -- the user actually requested a secured page. But it can also happen in more subtle ways -- a bug in an img tag with the src set to a secured url, an overly-inclusive url-pattern in the security filter config, etc. -- the user generally won't see the login page with bugs of this nature.
Can you describe in a little more detail the scenario where security filter is creating a session prematurely?
All,
> 1. user requests secured page
> 2. security filter creates a session (to save the URL the user was trying to reach)
> 3. login screen appears
I'd like to point out that this is how most application servers work when using form-based logins: their form authenticators will store the saved request in the session. Although the servlet specification does not mandate that the session be used for storage of the saved URL (or even that a session must be created prior to login), it is the most obvious strategy for performing this task.
-chris
We use Tomcat/Velocity/Tiles/Struts so no JSPs, but your point is understood. We went through all of our code and we are not calling a getSession(true) type of thing until after the user is logged in. We logged our filter start/ends. There was no session in the results until this exception in Security filter which showed the exception at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:231). Intentionally I placed this filter in between two other filters that I could log easily. It never got to the 3rd filter.
The SessionListenerLogger just is a session listener kicking off the exception above when session is created, similar to what was posted above.
Thank you. We will look into this more here. Maybe Tomcat is creating it somehow internally. There is the ability to turn off cookie use in Tomcat in its Context configuration, but we just would want no sessions until the user is logged in. We never had to worry about this before, but now we are concerned about search engines being hard on our site due to jsessionid showing up in their URLs.
Likely this is something we are doing, but your wisdom is appreciated very much.
JohnE
Prior to login, we have no getSession() or getSession(true), so it must be then maybe something Tomcat is doing as part of the filter. No clue.
Realization strikes. We do have one JSP and only one JSP -- a basic index.jsp that just forwards to our real home page link. Will try to see if the session=false will fix this issue later. The odd thing is where the exception occurred though. It occurred during the SecurityFilter.java:231 as the second of three filters, with the third filter not being reached. Not confident the fix above is the only reason, but at least it is a good chance.
Just wanted to say thank you. It seems that there are many other places where session is being created without my wishing it. So far, using something similar to your HttpSessionListener, I have been able to track down some issues. None of them so far are in my code, but rather in things like Struts. Found that in Struts 1.2.* that it puts a "locale" into the session automatically unless you turn it off in the struts-config file using session=false there.
Have another case of session to try to work out tonight along similar lines that seems to occur as part of Struts, Tiles, or Tomcat.
Seems that auto-session usage is a huge mistake as it automatically places a framework in jeopardy with SEO lowering their ability to compete. The "end result" should be the first thing on a framework's place, not technology bells and whistles.
Will write back once figure out other issues so that other people have this information.
Thanks again.
John,
You might want to read this page (http://randomcoder.com/articles/jsessionid-considered-harmful) and some of its related material. These guys offer some techniques to help avoid the session id being included in the URLs for search engines. Of course, reducing the number of sessions created is always good if you don't need to be creating them in the first place.
Good luck,
-chris
Agree, but it seems that Apache Tiles pre-2.0.5 creates them automatically unconfigurably. Was able to remove them out of Struts, but...it is difficult to get away from forced use of sessions when I would think it should be the default until perhaps authenticated.
Still trying to think of a way. Thank you for that link on "jsessionid-considered-harmful" the URL Christopher. It may be something I will do, but it also seems to prohibit the use of any users without cookies.
Google has said session id is not a concern nor is query strings in general, but based on the links I am seeing people save and such, I disagree and it is good to have an option. There are some URLs with jsessionid pointing to our site.
This is a challenge to figure yet a new challenge. There seems to be no clear solution except not having any of your applications use sessions in the first place. If only that were possible at the moment...
John,
If you choose to implement a filter that suppresses url-encoded session ids, you can always check the User-Agent string from the HTTP request headers. That way, you can suppress url-encoded session ids (or the session entirely, actually) only for clients such as "google" or whatever you want to use.
You can still service regular users whose web browsers supply a legitimate User-Agent string (and pretty much all do).
-chris