Hi,
Aaahh, I forgot about the comma seperator. I've been using slashes in my
setPage() calls.
Thanks,
g
ps. For interest sake, here's what the Apache people say about the %2F
problem:
> It is to prevent a CGI security hole. Say you had a CGI script that used
> the PATH_INFO to select other files (as is the most common use for path
> info), and I sent you
> script/..%2F..%2F..%2Fetc%2Fpasswd
> (keeping in mind that a person can make multiple requests looking for
> just the right combination). The NCSA server (when we last tested it)
> will perform its access checks before unescaping the %2F, and then provide
> the script with PATH_INFO="/../../../etc/passwd".
> The core Apache server protects against this for its own files, but CGI
> authors are, ummm, security-challenged. Some happily take the PATH_INFO
> and open it relative to whatever their script's root document may be.
> dir/../../../etc/passwd
> So, Apache does not allow %2F to be in PATH_INFO, which is a legitimate
> thing to do given that the server controls the path namespace.
> Now, I know that this causes problems with some scripts that depend on
> receiving encoded paths (as does a recent version of dienst, for
> example). There are three solutions for such systems:
> 1) Don't use path info to pass arguments containing embedded "/"
> 2) Modify Apache so that it passes-on the %2F, which technically
> violates the CGI spec and requires the script to be
apache-dependent.
> 3) Modify Apache so that it doesn't reject %2F, which may make your
> server a security problem. In that case, I'd recommend continuing
> to reject any occurrence of "..%2F", since that is the main
culprit.
-----Original Message-----
From: John McNally [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 20, 2000 6:32 PM
To: Turbine
Subject: Re: Apache quirk
Graeme Pyle wrote:
>
> Hi folks,
>
> I found a strange problem with Apache that is exposed by the way Turbine
> encodes URL parameters into the path of the request.
>
> It turns out that Apache doesn't like the '/' character encoded as '%2F'
> inside a URL path. If you have an action or screen in Turbine which is in
a
> subdirectory (eg. admin/index.vm), the '/' is encoded as '%2F' and Apache
> doesn't like that.
>
I think Apache is perfectly happy with either / or %2F, it does not make
a distinction between the two. I ran into this when building the
template system and after reading the url encoding spec several times I
was finally convinced that this is the correct interpretation. I chose
to use a comma (,) as the path separator.
>
> 1) Hack %2F checking out of Apache (The Apache maintainers know about the
> problem, in fact, allowing %2F is a security risk to them. Doesn't look
like
> they intend fixing it)
How is this a risk? I believe it is the proper interpretation.
>
> 2) Change the seperator used by Turbine
It's always been a comma.
>
> Comments/suggestions?
>
> g
>
> -----Original Message-----
> From: James Coltman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 20, 2000 4:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: TemplateSecureSessionValidator
>
> martin wrote:
>
> >there was a bug in TemplateInfo.java ... it is fixed in turbine-cvs ...
> >get the latest version or wait for the next tdk ..
>
> in response to:
> >> Which version of Turbine are you using? With TDK1.1a9 and
> >> TDK1.1b1, I get the same results. Is there something else
> >> I'm missing in TR.props?
> >>
> >> I even created another sessionvalidator and copied the code
> >> from TemplateSecureSessionValidator and put in debugging
> >> prints. Interestingly enough,
> >>
> >> data.getTemplateInfo().setScreenTemplate(
> >> TurbineResources.getString("template.login") );
> >> System.out.println(data.getTemplateInfo().getScreenTemplate());
> >>
> >> The second line prints the page I was maliciously trying to
> >> get to, rather than the data from template.login.
> >>
> >> However, the setMessage() call is working - the page I
> >> maliciously tried to go to shows me the login.message. -
> >> The template is just not getting set properly.
>
> I have tried use the the latest code from the one of the recent nightly
> builds and have found that I am getting a horrible exception response.
Could
> you direct me to a usable nightly build that I can intergrate with the
> TDK1.1b1, or do I need to use one of the TDK's from CVS.
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]