Re: Is there a better way to disable JSESSIONID in the URLs?
On 26.08.2010 23:29, Wesley Acheson wrote: On Sat, Aug 21, 2010 at 12:12 PM, Pidp...@pidster.com wrote: On 20/08/2010 22:40, Wesley Acheson wrote: I'm a bit lost with this thread. Are people suggesting I should submit a patch. I really wouldn't know where to begin looking. That's where the discussion was heading. Tomcat is Open Source. The first place to look would be SVN. http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ p Hi everyone, I've done this and was naturally quite nervous about it having never contributed to anything in this way. That's quite normal :) It gets better once you do it more regularly ;) Would It be too much to ask to get some feedback if you have time? I'd really appreciate it. Feedback about anything from the code changes to if you feel the bugzilla report was adaquate. It was a good initiative and I'm sure we will have a look at the patch. Please be patient though. If you don't see any progress (comments in the Bugzilla issue), then it is fine to nag after about one or two weeks. I do honestly appreciate that you are all busy but It could go a long way to encouraging new users to help chip in if they felt there was adaquate feedback. Much better to be honest though than to pamper to them. If anythings wrong with what I did I'd love to know but If it was okay I'd like to know also. If it gets committed to the Tomcat source, you will see, whether there was a need to change anything. All changes applied to the code are public. If this is a subject for the dev mail list then I'd appreciate being told that too. I didn't want to interrupt the dev mail list as it seems pretty busy with svn commits and bugzilla reports. It is in the middle of the two lists, since most of the discussion was here (users) I understand you reply here. If there is need to discuss technical details of the patch, the discussion will switch over to Bugzilla, or if the discussion switches topic, like starting to discuss a more general implementation thing it might switch to the dev list. In case your not in a threaded email client the link was https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 again. Thanks for starting to contribute! Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On Sat, Aug 21, 2010 at 12:12 PM, Pid p...@pidster.com wrote: On 20/08/2010 22:40, Wesley Acheson wrote: I'm a bit lost with this thread. Are people suggesting I should submit a patch. I really wouldn't know where to begin looking. That's where the discussion was heading. Tomcat is Open Source. The first place to look would be SVN. http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ p Hi everyone, I've done this and was naturally quite nervous about it having never contributed to anything in this way. Would It be too much to ask to get some feedback if you have time? I'd really appreciate it. Feedback about anything from the code changes to if you feel the bugzilla report was adaquate. I do honestly appreciate that you are all busy but It could go a long way to encouraging new users to help chip in if they felt there was adaquate feedback. Much better to be honest though than to pamper to them. If anythings wrong with what I did I'd love to know but If it was okay I'd like to know also. If this is a subject for the dev mail list then I'd appreciate being told that too. I didn't want to interrupt the dev mail list as it seems pretty busy with svn commits and bugzilla reports. In case your not in a threaded email client the link was https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 again. Regards, Wesley Acheson - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas ma...@apache.org wrote: On 22/08/2010 16:29, Wesley Acheson wrote: Sorry for bring this off list. I'll put it back on list if you think that appropriate. You think that the context is the correct place to put this? I thought maybe web.xml but I don't know if you can extend that or if its rigidly covered by the spec. web.xml is defined by the spec. You can't touch it. I started to do this on the connector is that incorrect? The configuration needs to be per context. Look at the sessionCookieName attribute as an example. For the place to actually diable it, look in the o.a.c.connector.Response.isEncodeable() method. If you look in the TC7 code, you'll see how the Servlet 3.0 stuff was implemented. How would one submit a patch? Sorry I've never done this for any project. Do I just attach the changed source files to bugzilla? or do I need to do a diff and create a patch file. Patch please, in diff -u format. Bugzilla is the right place. I'm on windows so I've never used patch and I am unsure how to create one. (unix patch file) I use TortoiseSVN and Eclipse on Windows. Both these tools generate suitable patch files. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Awesome dude (that you submitted the patch so quick - I've not looked at it in detail yet). Thanks! -Original Message- From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Sent: Monday, August 23, 2010 2:33 PM To: Tomcat Users List Subject: Re: Is there a better way to disable JSESSIONID in the URLs? https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas ma...@apache.org wrote: On 22/08/2010 16:29, Wesley Acheson wrote: Sorry for bring this off list. I'll put it back on list if you think that appropriate. You think that the context is the correct place to put this? I thought maybe web.xml but I don't know if you can extend that or if its rigidly covered by the spec. web.xml is defined by the spec. You can't touch it. I started to do this on the connector is that incorrect? The configuration needs to be per context. Look at the sessionCookieName attribute as an example. For the place to actually diable it, look in the o.a.c.connector.Response.isEncodeable() method. If you look in the TC7 code, you'll see how the Servlet 3.0 stuff was implemented. How would one submit a patch? Sorry I've never done this for any project. Do I just attach the changed source files to bugzilla? or do I need to do a diff and create a patch file. Patch please, in diff -u format. Bugzilla is the right place. I'm on windows so I've never used patch and I am unsure how to create one. (unix patch file) I use TortoiseSVN and Eclipse on Windows. Both these tools generate suitable patch files. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Yeah don't get too hopeful. I'm not that familiar with the tomcat code, however I think it works. On Mon, Aug 23, 2010 at 8:59 PM, Scott Hamilton scott.hamil...@plateau.com wrote: Awesome dude (that you submitted the patch so quick - I've not looked at it in detail yet). Thanks! -Original Message- From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Sent: Monday, August 23, 2010 2:33 PM To: Tomcat Users List Subject: Re: Is there a better way to disable JSESSIONID in the URLs? https://issues.apache.org/bugzilla/show_bug.cgi?id=49811 On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas ma...@apache.org wrote: On 22/08/2010 16:29, Wesley Acheson wrote: Sorry for bring this off list. I'll put it back on list if you think that appropriate. You think that the context is the correct place to put this? I thought maybe web.xml but I don't know if you can extend that or if its rigidly covered by the spec. web.xml is defined by the spec. You can't touch it. I started to do this on the connector is that incorrect? The configuration needs to be per context. Look at the sessionCookieName attribute as an example. For the place to actually diable it, look in the o.a.c.connector.Response.isEncodeable() method. If you look in the TC7 code, you'll see how the Servlet 3.0 stuff was implemented. How would one submit a patch? Sorry I've never done this for any project. Do I just attach the changed source files to bugzilla? or do I need to do a diff and create a patch file. Patch please, in diff -u format. Bugzilla is the right place. I'm on windows so I've never used patch and I am unsure how to create one. (unix patch file) I use TortoiseSVN and Eclipse on Windows. Both these tools generate suitable patch files. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
Sorry for bring this off list. I'll put it back on list if you think that appropriate. You think that the context is the correct place to put this? I thought maybe web.xml but I don't know if you can extend that or if its rigidly covered by the spec. I started to do this on the connector is that incorrect? How would one submit a patch? Sorry I've never done this for any project. Do I just attach the changed source files to bugzilla? or do I need to do a diff and create a patch file. I'm on windows so I've never used patch and I am unsure how to create one. (unix patch file) Regards, Wesley Acheson On Sat, Aug 21, 2010 at 12:12 PM, Pid p...@pidster.com wrote: On 20/08/2010 22:40, Wesley Acheson wrote: I'm a bit lost with this thread. Are people suggesting I should submit a patch. I really wouldn't know where to begin looking. That's where the discussion was heading. Tomcat is Open Source. The first place to look would be SVN. http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ p On Fri, Aug 20, 2010 at 7:47 PM, Pid p...@pidster.com wrote: On 20/08/2010 17:35, Christopher Schultz wrote: Pid, On 8/20/2010 8:33 AM, Pid wrote: On 19/08/2010 20:41, Wesley Acheson wrote: On Thu, Aug 19, 2010 at 6:25 PM, Len Popp len.p...@gmail.com wrote: On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before. You could file an enhancement request in Bugzilla, but it would be more likely to get attention if it came with a patch. I can't comment as to whether it would be approved or not. This sounds like something that could easily be implemented as a Valve. My understanding is that the only place where the jsessionid can't be removed from URLs by a Filter is during the authentication process. A Valve can be inserted /before/ the authentication/authorization Valve(s) and therefore override the encodeURL behavior to perform /no/ URL rewriting. Maybe one of the TC devs can tell us how to insert a Valve /before/ the AAA valves that are automatically set up by the security configuration in web.xml, but never explicitly defined using a Valve element anywhere. Maybe look to see how it's implemented in v7.0 and hack something up. Taking Mark's hint and setting something on the Context, with effect on StandardContextValve maybe... p -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On 22/08/2010 16:29, Wesley Acheson wrote: Sorry for bring this off list. I'll put it back on list if you think that appropriate. You think that the context is the correct place to put this? I thought maybe web.xml but I don't know if you can extend that or if its rigidly covered by the spec. web.xml is defined by the spec. You can't touch it. I started to do this on the connector is that incorrect? The configuration needs to be per context. Look at the sessionCookieName attribute as an example. For the place to actually diable it, look in the o.a.c.connector.Response.isEncodeable() method. If you look in the TC7 code, you'll see how the Servlet 3.0 stuff was implemented. How would one submit a patch? Sorry I've never done this for any project. Do I just attach the changed source files to bugzilla? or do I need to do a diff and create a patch file. Patch please, in diff -u format. Bugzilla is the right place. I'm on windows so I've never used patch and I am unsure how to create one. (unix patch file) I use TortoiseSVN and Eclipse on Windows. Both these tools generate suitable patch files. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On Sun, Aug 22, 2010 at 5:55 PM, Mark Thomas ma...@apache.org wrote: On 22/08/2010 16:29, Wesley Acheson wrote: Sorry for bring this off list. I'll put it back on list if you think that appropriate. You think that the context is the correct place to put this? I thought maybe web.xml but I don't know if you can extend that or if its rigidly covered by the spec. web.xml is defined by the spec. You can't touch it. Okay I thought this is where I saw it in Resin 2. I wan't actually going to do it but I think the specs should allow vendor extensions to web.xml. I started to do this on the connector is that incorrect? The configuration needs to be per context. Look at the sessionCookieName attribute as an example. For the place to actually diable it, look in the o.a.c.connector.Response.isEncodeable() method. If you look in the TC7 code, you'll see how the Servlet 3.0 stuff was implemented. Great this is where I put my initial code. How would one submit a patch? Sorry I've never done this for any project. Do I just attach the changed source files to bugzilla? or do I need to do a diff and create a patch file. Patch please, in diff -u format. Bugzilla is the right place. I'm on windows so I've never used patch and I am unsure how to create one. (unix patch file) I use TortoiseSVN and Eclipse on Windows. Both these tools generate suitable patch files. Thanks. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Subject: Re: Is there a better way to disable JSESSIONID in the URLs? I wan't actually going to do it but I think the specs should allow vendor extensions to web.xml. That would be a really bad idea, and pretty much kill off any chance of portability. Separate container-specific structures (such as what Tomcat uses) are much less intrusive. We don't want to recreate the SQL dialect mayhem... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On 20/08/2010 22:40, Wesley Acheson wrote: I'm a bit lost with this thread. Are people suggesting I should submit a patch. I really wouldn't know where to begin looking. That's where the discussion was heading. Tomcat is Open Source. The first place to look would be SVN. http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ p On Fri, Aug 20, 2010 at 7:47 PM, Pid p...@pidster.com wrote: On 20/08/2010 17:35, Christopher Schultz wrote: Pid, On 8/20/2010 8:33 AM, Pid wrote: On 19/08/2010 20:41, Wesley Acheson wrote: On Thu, Aug 19, 2010 at 6:25 PM, Len Popp len.p...@gmail.com wrote: On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before. You could file an enhancement request in Bugzilla, but it would be more likely to get attention if it came with a patch. I can't comment as to whether it would be approved or not. This sounds like something that could easily be implemented as a Valve. My understanding is that the only place where the jsessionid can't be removed from URLs by a Filter is during the authentication process. A Valve can be inserted /before/ the authentication/authorization Valve(s) and therefore override the encodeURL behavior to perform /no/ URL rewriting. Maybe one of the TC devs can tell us how to insert a Valve /before/ the AAA valves that are automatically set up by the security configuration in web.xml, but never explicitly defined using a Valve element anywhere. Maybe look to see how it's implemented in v7.0 and hack something up. Taking Mark's hint and setting something on the Context, with effect on StandardContextValve maybe... p -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Is there a better way to disable JSESSIONID in the URLs?
On 19/08/2010 20:41, Wesley Acheson wrote: On Thu, Aug 19, 2010 at 6:25 PM, Len Popp len.p...@gmail.com wrote: On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before. You could file an enhancement request in Bugzilla, but it would be more likely to get attention if it came with a patch. I can't comment as to whether it would be approved or not. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Is there a better way to disable JSESSIONID in the URLs?
On 20/08/2010 14:33, Pid wrote: On 19/08/2010 20:41, Wesley Acheson wrote: Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before. You could file an enhancement request in Bugzilla, but it would be more likely to get attention if it came with a patch. I can't comment as to whether it would be approved or not. That depends on the patch ;) Personally, I like the idea. Things I'd look for in a patch: - is it configurable per context - how invasive is it I'd add that this is part of Servlet 3.0 and is supported in Tomcat 7. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 8/20/2010 8:33 AM, Pid wrote: On 19/08/2010 20:41, Wesley Acheson wrote: On Thu, Aug 19, 2010 at 6:25 PM, Len Popp len.p...@gmail.com wrote: On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before. You could file an enhancement request in Bugzilla, but it would be more likely to get attention if it came with a patch. I can't comment as to whether it would be approved or not. This sounds like something that could easily be implemented as a Valve. My understanding is that the only place where the jsessionid can't be removed from URLs by a Filter is during the authentication process. A Valve can be inserted /before/ the authentication/authorization Valve(s) and therefore override the encodeURL behavior to perform /no/ URL rewriting. Maybe one of the TC devs can tell us how to insert a Valve /before/ the AAA valves that are automatically set up by the security configuration in web.xml, but never explicitly defined using a Valve element anywhere. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxurrYACgkQ9CaO5/Lv0PD18QCfa1cistS8pfMGe9mcZrWyOmBI ybwAn2gAE7V/9I7vZIILB1h7hS2EZnWn =9hMX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On 20/08/2010 17:35, Christopher Schultz wrote: Pid, On 8/20/2010 8:33 AM, Pid wrote: On 19/08/2010 20:41, Wesley Acheson wrote: On Thu, Aug 19, 2010 at 6:25 PM, Len Popp len.p...@gmail.com wrote: On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before. You could file an enhancement request in Bugzilla, but it would be more likely to get attention if it came with a patch. I can't comment as to whether it would be approved or not. This sounds like something that could easily be implemented as a Valve. My understanding is that the only place where the jsessionid can't be removed from URLs by a Filter is during the authentication process. A Valve can be inserted /before/ the authentication/authorization Valve(s) and therefore override the encodeURL behavior to perform /no/ URL rewriting. Maybe one of the TC devs can tell us how to insert a Valve /before/ the AAA valves that are automatically set up by the security configuration in web.xml, but never explicitly defined using a Valve element anywhere. Maybe look to see how it's implemented in v7.0 and hack something up. Taking Mark's hint and setting something on the Context, with effect on StandardContextValve maybe... p -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Is there a better way to disable JSESSIONID in the URLs?
I'm a bit lost with this thread. Are people suggesting I should submit a patch. I really wouldn't know where to begin looking. On Fri, Aug 20, 2010 at 7:47 PM, Pid p...@pidster.com wrote: On 20/08/2010 17:35, Christopher Schultz wrote: Pid, On 8/20/2010 8:33 AM, Pid wrote: On 19/08/2010 20:41, Wesley Acheson wrote: On Thu, Aug 19, 2010 at 6:25 PM, Len Popp len.p...@gmail.com wrote: On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before. You could file an enhancement request in Bugzilla, but it would be more likely to get attention if it came with a patch. I can't comment as to whether it would be approved or not. This sounds like something that could easily be implemented as a Valve. My understanding is that the only place where the jsessionid can't be removed from URLs by a Filter is during the authentication process. A Valve can be inserted /before/ the authentication/authorization Valve(s) and therefore override the encodeURL behavior to perform /no/ URL rewriting. Maybe one of the TC devs can tell us how to insert a Valve /before/ the AAA valves that are automatically set up by the security configuration in web.xml, but never explicitly defined using a Valve element anywhere. Maybe look to see how it's implemented in v7.0 and hack something up. Taking Mark's hint and setting something on the Context, with effect on StandardContextValve maybe... p -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
I was going to write this off list because its off topic, but maybe the information is useful. On Thu, Aug 19, 2010 at 5:19 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wesley, On 8/17/2010 6:05 PM, Wesley Acheson wrote: I know of no better way to fix this. This is what we *had* to do to pass PCI too so its no small deal. Wow, who made you disable jsessionids in URLs to achieve PCI compliance? Whoever did that doesn't understand Java webapp security. Or Internet security for that matter. :( Of course, there might just be some heavy-handed PCI requirements that the working group pulled out of their asses in a few minutes and then got on with a great deal of self-congratulations for making the Internet safe. - -chris It was a third party ethical hacker, who's report we needed to be clean for PCI. In general though I have to say I agree and the ;jsessionid thing is pretty insecure. Yes you can regenerate sessionId's after a client logs in. (Though not in our case). Yes It only appears on the first page if the user doesn't have cookies enabled. We disabled both accepting of URL sessionId's and the session encoding URLs. Our application has worked well since with no problems. In fact better as we can cache certain pages in their entirity without being concerned with url rewriting. If we use relative URLs to static content served by Apache Httpd this now works too as otherwise Apache httpd gives a 404 (correctly) if there is a jsessionId in the URL. In my honest opinion the URL jsessionid thing is a bad idea. Its not even added as parameter to the URL but rather part of the request URL itself. So many websites don't function without cookies anyway. It would be just better to use session cookies or at least leave an option in server.xml or context xml to disable it. Imagine the following senario. Someone goes to malicious-site.com which has some javascript running in the background that posts to one of your forms. Card withdrawal for instance. This javascript can post all the details to your site, however it cannot write cookies for your domain. However if it was either able to guess a jessionid or one could have been used from somewhere else and jessionid is a parameter in the url theres nothing stopping them posting to http://yoursite/withdrawMoney;jsessionid=xxx. Yes I know you need more security measures than that in place for this type of attack but I still believe that its valuable being able to disable it. Resin does allow you I wish tomcat would. Regards, Wesley Acheson - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Sorry to pull the thread back to my original problem, but I have one more question here. So far it looks like there's no way to prevent JSESSIONIDs from being injected into URLs that Tomcat might encode unless you implement a servlet filter to override that behavior. My follow-up question is this: given the increasing emphasis on security (and acknowledging that there's as much fear-mongering as there is legitimate threats involved in that business and both cost money and time regardless of the legitimacy of the issue), does it make sense to for Tomcat, and maybe even the servlet spec, to provide the option for the servlet container to disable this functionality at the container level, e.g. with a container configuration switch somewhere? . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On 19/08/2010 13:32, Scott Hamilton wrote: Sorry to pull the thread back to my original problem, but I have one more question here. So far it looks like there's no way to prevent JSESSIONIDs from being injected into URLs that Tomcat might encode unless you implement a servlet filter to override that behavior. My follow-up question is this: given the increasing emphasis on security (and acknowledging that there's as much fear-mongering as there is legitimate threats involved in that business and both cost money and time regardless of the legitimacy of the issue), does it make sense to for Tomcat, and maybe even the servlet spec, to provide the option for the servlet container to disable this functionality at the container level, e.g. with a container configuration switch somewhere? You could always submit a patch and see what the devs think. ;) p The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Is there a better way to disable JSESSIONID in the URLs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wesley, On 8/19/2010 3:57 AM, Wesley Acheson wrote: We disabled both accepting of URL sessionId's and the session encoding URLs. Our application has worked well since with no problems. In fact better as we can cache certain pages in their entirity without being concerned with url rewriting. If we use relative URLs to static content served by Apache Httpd this now works too as otherwise Apache httpd gives a 404 (correctly) if there is a jsessionId in the URL. Apache httpd's behavior is a matter of opinion at this point. I believe it should /not/ give you 404s, but there are at least two workarounds for that: mod_rewrite and mod_jk's StripSession setting. In my honest opinion the URL jsessionid thing is a bad idea. Its not even added as parameter to the URL but rather part of the request URL itself. The HTTP/URL spec calls this a parameter: it's /not/ part of the path. So many websites don't function without cookies anyway. It would be just better to use session cookies or at least leave an option in server.xml or context xml to disable it. The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. Imagine the following senario. Someone goes to malicious-site.com which has some javascript running in the background that posts to one of your forms. Card withdrawal for instance. This javascript can post all the details to your site, however it cannot write cookies for your domain. However if it was either able to guess a jessionid or one could have been used from somewhere else and jessionid is a parameter in the url theres nothing stopping them posting to http://yoursite/withdrawMoney;jsessionid=xxx. What stops javascript from making a request to a site and adding headers like, for instance the Cookie header? I haven't hacked around with javascript capabilities so I really don't know if that's legal to do. I would imagine that most web browsers have robust enough javascript support that a telnet client could be written on them. Yes I know you need more security measures than that in place for this type of attack but I still believe that its valuable being able to disable it. Resin does allow you I wish tomcat would. As is often said, patches are always welcome. ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxtVVwACgkQ9CaO5/Lv0PDMhACgtlf12f4RGKslsuNPUEFZujTK 1dAAoKZQWuZLBG4T543mzddDtHE3eWvI =PBrQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On Thu, Aug 19, 2010 at 6:25 PM, Len Popp len.p...@gmail.com wrote: On Thu, Aug 19, 2010 at 12:01, Christopher Schultz ch...@christopherschultz.net wrote: The servlet specification mandates this behavior. Tomcat simply must support it. The spec says nothing of configurability, so Tomcat does not provide any. Hence the need to write a filter to achieve your desired behavior. That's not inviolable dogma. Tomcat does have some settings that make it operate out-of-spec, e.g. non-standard cookie parsing. I don't see why an option couldn't be added to disable JSESSIONID in URLs, if enough people would find it useful. -- Len Is there anywhere we could vote for such a feature? I know Resin has it as I've stated before.
Re: Is there a better way to disable JSESSIONID in the URLs?
Caldarale, Charles R wrote: From: Scott Hamilton [mailto:scott.hamil...@plateau.com] Subject: RE: Is there a better way to disable JSESSIONID in the URLs? I could be missing something, but on a request where a session is created it appears as though Tomcat will both set the cookie AND do any necessary URL rewriting in order to ensure that the cookie is preserved. Sorry, you're right; at that point Tomcat doesn't know if the client supports cookies. However, when skimming through the Tomcat code, the only internal call to encodeURL() that I can find appears to be called only for relative URLs, so possibly making your initial URLs absolute might avoid appending the jsessionid. (But I could have easily missed a call, and there may be another method that's doing the appending.) The issue in question isn't so much about determined hackers but hapless users who will bookmark URLs or worse, copy URLs to email to their co-workers. Hapless being the operative word. I think you're stuck with using a filter. Could/should not Tomcat at least verify, when it gets a JSESSIONID from a client and retrieves the corresponding session information, that the IP address of this current client matches the client IP address (which would have been) previously stored in the session ? Or would this introduce other problems ? I know that it is not really a solution, because hapless users will anyway continue (mostly innocently) to email links to their colleagues, and they will wonder why they do not work. And it is not a foolproof security system either. But at least then these links would not so easily work and give cold sweats to these people's network admins. If I understand correctly how it works, then currently the following scenario is possible, isn't it ? Within a corporate LAN, all users must login into their workstation using some form of network login (in 99% of the practical cases, that would be Windows NTLM). Then they call up an application residing on a corporate Tomcat host. This host is configured so as to automatically pick up the user's network user-id (through e.g. Jespa, or Waffle, or similar), and use it as the Tomcat user-id. Then this first user session gets a tomcat session and associated JSESSIONID. The application checks that the user session is authenticated, but also controls access to some information in function of this user-id. Now this particular user gets a link to a resource, accessible to his user-id, and then copies that link to a colleague (also logged-in into the corporate network), who normally would not have access to that resource. But because the link contains the jsessionid of the first user, the colleague would gain access to the resource, without either one of them even thinking about it. This is inside a corporate LAN, where one would normally tend to consider communications as trusted, and thus to not really need SSL. The authentication method is fairly secure, in the sense that passwords are not exchanged, and Tomcat can trust the user-id as received by the first user's authentication method. But by simply exchanging this link, the users unwittingly or not break the access control mechanisms buried deep into an application. Furthermore, now these two users can continue to interact with the application, both within the same Tomcat session, although they are on different workstations altogether ? To me, that sounds really bad. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wesley, On 8/17/2010 6:05 PM, Wesley Acheson wrote: I know of no better way to fix this. This is what we *had* to do to pass PCI too so its no small deal. Wow, who made you disable jsessionids in URLs to achieve PCI compliance? Whoever did that doesn't understand Java webapp security. Or Internet security for that matter. :( Of course, there might just be some heavy-handed PCI requirements that the working group pulled out of their asses in a few minutes and then got on with a great deal of self-congratulations for making the Internet safe. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxsorsACgkQ9CaO5/Lv0PAGzgCfXtTF9BFrRTGvrQ4YXd8ZjXqh CFkAn39TkdK48bu5kItvxqoFrDHOgv5S =s8g7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, Wow. I wrote a book. Sorry for my uncharacteristically long exposition. On 8/18/2010 5:40 AM, André Warnier wrote: Could/should not Tomcat at least verify, when it gets a JSESSIONID from a client and retrieves the corresponding session information, that the IP address of this current client matches the client IP address (which would have been) previously stored in the session ? Or would this introduce other problems ? Sometimes a user's IP changes for one of several reasons: 1. Internet connection dies / re-establishes with a new BOOTP/DHCP IP 2. Came through a different proxy on different requests 3. You have AOL, who apparently loves to play games with IPs This is a good security feature to allow users to opt-into, though. There's a filter in securityfilter (have I committed it, yet?) to do just this, and it's user-selectable at login (or any time? I'll have to look at the code again). I know that it is not really a solution, because hapless users will anyway continue (mostly innocently) to email links to their colleagues, and they will wonder why they do not work. If security has been implemented correctly, Tomcat will ask the user for their credentials and ultimately give access to the requested resource once authentication has been completed successfully. That's part of the spec: one that works quite well for users IMO. If I understand correctly how it works, then currently the following scenario is possible, isn't it ? But because the link contains the jsessionid of the first user, the colleague would gain access to the resource, without either one of them even thinking about it. Yup. This is called session hijacking. It can be performed against any web server using non-SSL sessions (I mean an SSL-session, not just an HTTP session being used over HTTPS). Note that disabling the jsessionid parameter being added to URLs does not in the slightest way prevent a hacker from crafting a URL that contains a jsessionid and using it to hijack a session. Not only that, but there's no spec or Tomcat requirement that the session be accessed via SSL. That means that if you, André (the good guy) log into your secure web application using HTTPS and establish a session, I (the bad guy) can hit http://yourserver/secretStuff.jsp?jsessionid=12345 and, if I've guessed your session id correctly, I get to masquerade as you. In fact, I believe Tomcat will continue sending Set-Cookie headers, so once I've sent my specially-crafted URL to the server, I don't even have to go through the pain of re-writing every URL I see: I've got the same cookie you do, now, too (except mine probably doesn't have secure=true set). Note that guessing a session id is non-trivial, so it may take a long time to accomplish. The good news for hackers is that there is no built-in anti-hacking mechanism to prohibit remote users from simply attempting to hijack session id after session id, so they can try all day to break into a standard Tomcat server. No, I haven't yet written a filter that can capture these attacks and try to mitigate them. This is inside a corporate LAN, where one would normally tend to consider communications as trusted, and thus to not really need SSL. Hah. Trust no one. But by simply exchanging this link, the users unwittingly or not break the access control mechanisms buried deep into an application. Furthermore, now these two users can continue to interact with the application, both within the same Tomcat session, although they are on different workstations altogether ? To me, that sounds really bad. It's not terribly good. Note that the presence of the jsessionid in the URL is not really the attack vector: it just makes the attack vector slightly more convenient for hackers or idiots. Cookies have the same danger in that anyone can send any cookie to any web server. The real problem is allowing remote clients to self-authenticate -- that is, provide an otherwise non-corroborated credential (that's the session id) to the server. The only really good way to secure a session to a single user is to use SSL client certificates with the cert fingerprint stored in the session. Even then, the client cert can be shared with others so you're really just shrinking the pool of potential session hijackers to those who might be able to get their hands on an SSL cert. With credentials, it's always something you know or something you have (or something you /are/, but that's not practical for web-based security). Something you know can always be guessed if given enough time. Something you have is almost always better than something you know, especially if it's not duplicatable (is that a word?) like one of those dongles they used to use for software licenses. Coupling the two is pretty much as good as you can get (which is why they call it two-factor authentication and why it gets so much hype). By the way, anyone not using SSL certificates
Re: Is there a better way to disable JSESSIONID in the URLs?
On Wed, Aug 18, 2010 at 12:01 AM, Scott Hamilton scott.hamil...@plateau.com wrote: Using Tomcat 6.0.29, but I think this is version-independent (correct me if I'm wrong), at least for the 6.0.x versions. From what I understand (see http://randomcoder.com/articles/jsessionid-considered-harmful for instance - I also scanned various aspects of the tomcat source code) there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. The only way I've seen how to do this, as suggested on the site I referenced, is to put into place a servlet filter. I'd like to know if I'm missing anything - is there a better way to do this? We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out (especially when they demonstrate that you can get a URL from the app, email it to someone else, and have that person magically bypass authentication and assume the role of the other user - of course as long as the session is still valid). We are comfortable saying that in order to use our application you need to have cookies enabled, so I'm making the assumption that if we disable the feature of putting JSESSIONID into the URLs, either through a nice global switch or else a servlet filter, cookie-based session setting/tracking will still function just as we expect it. Finally, anyone know why this isn't already in the servlet spec? Seems like with more and more concern over web application security that this would be something the spec should address? Thanks, Scott . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. I know of no better way to fix this. This is what we *had* to do to pass PCI too so its no small deal. However the filter does work wondefully with minimal overhead. Regards, Wesley Acheson - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
From: Scott Hamilton [mailto:scott.hamil...@plateau.com] Subject: Is there a better way to disable JSESSIONID in the URLs? there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
Thanks for the reply. Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. I could be missing something, but on a request where a session is created it appears as though Tomcat will both set the cookie AND do any necessary URL rewriting in order to ensure that the cookie is preserved. If the session (a) already exists and (b) was received in the request through a cookie reference it will NOT do the URL rewriting. I'm assuming this is to cover the bases and ensure a JSESSIONID gets injected into the following requests regardless of the client's cookie acceptance policy. And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. You're absolutely correct, and SSL is used for our security-conscious customers. The issue in question isn't so much about determined hackers but hapless users who will bookmark URLs or worse, copy URLs to email to their co-workers. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, August 17, 2010 6:16 PM To: Tomcat Users List Subject: RE: Is there a better way to disable JSESSIONID in the URLs? From: Scott Hamilton [mailto:scott.hamil...@plateau.com] Subject: Is there a better way to disable JSESSIONID in the URLs? there is no way to disable tomcat from putting the JSESSIONID in URLs automatically with a nice friendly global switch/property. Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. We have an app whose security is a concern for our customers, and JSESSIONIDs appearing in the URLs freak them out And the id value in a cookie doesn't? What stops anyone from e-mailing the cookie to someone else? If someone is truly concerned about security, then they *must* run *all* traffic through SSL. If the customers don't do that, they're not really concerned, despite whatever words they're using. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org . The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Is there a better way to disable JSESSIONID in the URLs?
On 2010-08-17, at 18:15, Caldarale, Charles R chuck.caldar...@unisys.com wrote: Tomcat won't put the jsessionid in the URL unless cookies are disabled. If they are, then your webapp could refuse to talk to the client. That's not true. Tomcat doesn't know if cookies are available until the second request, so the first page you get is full of URLs with jsessionids. Also search engine bots don't seem to use cookies. I saw lots of pointless re-re-re-crawling by search bots until I cleaned up the URLs. -- Len - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a better way to disable JSESSIONID in the URLs?
From: Scott Hamilton [mailto:scott.hamil...@plateau.com] Subject: RE: Is there a better way to disable JSESSIONID in the URLs? I could be missing something, but on a request where a session is created it appears as though Tomcat will both set the cookie AND do any necessary URL rewriting in order to ensure that the cookie is preserved. Sorry, you're right; at that point Tomcat doesn't know if the client supports cookies. However, when skimming through the Tomcat code, the only internal call to encodeURL() that I can find appears to be called only for relative URLs, so possibly making your initial URLs absolute might avoid appending the jsessionid. (But I could have easily missed a call, and there may be another method that's doing the appending.) The issue in question isn't so much about determined hackers but hapless users who will bookmark URLs or worse, copy URLs to email to their co-workers. Hapless being the operative word. I think you're stuck with using a filter. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
