[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Pending Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Jules Gosnell (jules_gosnell) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Jules Gosnell (jules_gosnell) Date: 2003-01-15 10:22 Message: Logged In: YES user_id=49106 The fix is in (Branch_3_0 and 3_2) - please confirm resolution so I can close this. Jules -- Comment By: Scott M Stark (starksm) Date: 2003-01-15 04:41 Message: Logged In: YES user_id=175228 Edit jbossweb.sar/webdefault.xml and set the redirectWelcome init-param of the default servlet to true to have welcome pages secured. See bug 621521 for the details of what is going on. -- Comment By: Peter Luttrell (objec) Date: 2003-01-15 02:25 Message: Logged In: YES user_id=472835 Based on gregs comments, it sounds like this is reproduceable via much simplier means then my case. My case: i am hitting my webapp by http://myserver/mycontext/ based on my deployment descriptor welcome-file-list welcome-fileindex.html/welcome-file /welcome-file-list jetty should take me to http://myserver/mycontext/index.html, which is this: html head titleMy Company Name/title meta http-equiv=refresh content=0;URL=index.jsp /head body /body /html So somewhere there's a problem. I'm doing this rerouting becase i've secured index.jsp and i can't make this the welcome page because Jetty does not check security on this page. I would prefer that it did, however i believe that this is an unspeced part of the spec. I don't know any other way to do this: I need to log in directly from the page that results from hitting the context directly. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 20:56 Message: Logged In: YES user_id=44062 A simple test case would be to have a servlet that looks at getPathInfo to see if a path param is included in it. I had thought it would effect all requests - but in retesting it only appears to be effecting connections via mod_jk and AJP13 I'll do some extra tests and see if I can come up with a normal HTTP test case. -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 19:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 09:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By:
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 09:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 01:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 22:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 11:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 11:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 01:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-13 17:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 14:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 20:56 Message: Logged In: YES user_id=44062 A simple test case would be to have a servlet that looks at getPathInfo to see if a path param is included in it. I had thought it would effect all requests - but in retesting it only appears to be effecting connections via mod_jk and AJP13 I'll do some extra tests and see if I can come up with a normal HTTP test case. -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 19:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 09:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 01:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 22:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Peter Luttrell (objec) Date: 2003-01-14 20:25 Message: Logged In: YES user_id=472835 Based on gregs comments, it sounds like this is reproduceable via much simplier means then my case. My case: i am hitting my webapp by http://myserver/mycontext/ based on my deployment descriptor welcome-file-list welcome-fileindex.html/welcome-file /welcome-file-list jetty should take me to http://myserver/mycontext/index.html, which is this: html head titleMy Company Name/title meta http-equiv=refresh content=0;URL=index.jsp /head body /body /html So somewhere there's a problem. I'm doing this rerouting becase i've secured index.jsp and i can't make this the welcome page because Jetty does not check security on this page. I would prefer that it did, however i believe that this is an unspeced part of the spec. I don't know any other way to do this: I need to log in directly from the page that results from hitting the context directly. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 14:56 Message: Logged In: YES user_id=44062 A simple test case would be to have a servlet that looks at getPathInfo to see if a path param is included in it. I had thought it would effect all requests - but in retesting it only appears to be effecting connections via mod_jk and AJP13 I'll do some extra tests and see if I can come up with a normal HTTP test case. -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 13:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 03:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-13 19:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 16:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 22:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 11:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Scott M Stark (starksm) Date: 2003-01-13 17:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 14:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_id=22866 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
