Bugs item #667341, was opened at 2003-01-13 19:24
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_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-file>index.html</welcome-file>
</welcome-file-list>
jetty should take me to
http://<myserver>/<mycontext>/index.html, which is this:
<html>
<head>
<title>My 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: 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=detail&atid=376685&aid=667341&group_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
