Tomcat 3.2 declarative security drops query string

[Willie Wheeler <ww...@andrew.cmu.edu>]

Hi all,

	I am using Tomcat 3.2 beta 2, and for my app, I've declared in the web.xml
deployment descriptor a security constraint on a web resource using the URI
path

	/engine/*

Now most of the time when someone actually requests a resource from
/engine/*, they will do so using a query string.  The j_security_check
intercepts
the request, does the login, and then redirects the browser at the page that
was originally requested.  Only problem is that the query string has now
disappeared!  Is this a bug?  Or is there some other way that I'm supposed
to handle this?

	Thanks,
	Willie

Re: Tomcat 3.2 declarative security drops query string

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Thanks for the bug report, and the suggested fix.  I just committed a
patch to do this
on the main CVS branch; it will probably get adopted into the 3.2
release branch as
well.

Craig McCLanahan


Willie Wheeler wrote:

> By the way, I looked at the source code, and the reason it does this is that
> it redirects to request.getRequestURI(), which returns the URL up to but not
> including the query string.  The specs say that it should redirect the user
> to the originally requested URL.  I'm not sure whether that technically
> includes the query string or not, but if not, it seems crazy that I wouldn't
> be able to protect resources that want query strings...
>
>         Willie
>
> -----Original Message-----
> From: Willie Wheeler [mailto:wwheeler@andrew.cmu.edu]
> Sent: Friday, July 28, 2000 11:23 AM
> To: general@jakarta.apache.org
> Subject: Tomcat 3.2 declarative security drops query string
>
> Hi all,
>
>         I am using Tomcat 3.2 beta 2, and for my app, I've declared in the web.xml
> deployment descriptor a security constraint on a web resource using the URI
> path
>
>         /engine/*
>
> Now most of the time when someone actually requests a resource from
> /engine/*, they will do so using a query string.  The j_security_check
> intercepts
> the request, does the login, and then redirects the browser at the page that
> was originally requested.  Only problem is that the query string has now
> disappeared!  Is this a bug?  Or is there some other way that I'm supposed
> to handle this?
>
>         Thanks,
>         Willie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

RE: Tomcat 3.2 declarative security drops query string

[Willie Wheeler <ww...@andrew.cmu.edu>]

By the way, I looked at the source code, and the reason it does this is that
it redirects to request.getRequestURI(), which returns the URL up to but not
including the query string.  The specs say that it should redirect the user
to the originally requested URL.  I'm not sure whether that technically
includes the query string or not, but if not, it seems crazy that I wouldn't
be able to protect resources that want query strings...

	Willie


-----Original Message-----
From: Willie Wheeler [mailto:wwheeler@andrew.cmu.edu]
Sent: Friday, July 28, 2000 11:23 AM
To: general@jakarta.apache.org
Subject: Tomcat 3.2 declarative security drops query string


Hi all,

	I am using Tomcat 3.2 beta 2, and for my app, I've declared in the web.xml
deployment descriptor a security constraint on a web resource using the URI
path

	/engine/*

Now most of the time when someone actually requests a resource from
/engine/*, they will do so using a query string.  The j_security_check
intercepts
the request, does the login, and then redirects the browser at the page that
was originally requested.  Only problem is that the query string has now
disappeared!  Is this a bug?  Or is there some other way that I'm supposed
to handle this?

	Thanks,
	Willie





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org