Mailing-List: contact jspwiki-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Message-id: <2B145127-837F-4C98-85D5-CBA35EB6FC14@mac.com>
From: Andrew Jaquith <andrew.jaquith@mac.com>
To: jspwiki-user@incubator.apache.org
In-reply-to: <485A0DB3.1040703@ops.co.at>
Subject: Re: url rewriting supported?
Date: Thu, 19 Jun 2008 15:39:06 -0400
References: <485919CA.9000902@ops.co.at>
 <02C1EF06-C327-4A18-B967-1C410894D3B5@mac.com> <48593648.7010409@ops.co.at>
 <485967B4.8010401@abstrakt.de> <485A0DB3.1040703@ops.co.at>

Simon --

I've been gently tweaking Janne from time to time about externalizing  
the URL constructors in a similar manner to what you describe,  
although the use I had in mind wasn't related to session IDs.

Something like http://tuckey.org/urlrewrite/ would do nicely, and  
would certainly allow us to implement custom URL schemes without  
having JSPWiki needing to be aware of how the URLs were made. The  
trade-off, as always, is memory and some performance.

For 3.0, this might happen, or might not.

Andrew

On Jun 19, 2008, at 3:41 AM, Simon Kitching wrote:

> Olaf Kock schrieb:
>> Simon Kitching schrieb:
>>
>>> By the way, I don't see cookies as a lot more secure. The cookie  
>>> text is
>>> also sent in plain text in both the request and response bodies.  
>>> There
>>> aren't many cases where someone can intercept the url but not the
>>> cookies. But thanks for the reference to OWASP; I'll have a look  
>>> at what
>>> they say about that.
>>>
>>
>> Hi,
>>
>> I do get your point with the dev environment and logging in multiple
>> times. However, even though http transfer is the same for urls and
>> cookies the url may be transferred for referred images and links to
>> other sites as the referrer, e.g. the url of a page that a link was
>> clicked on.
>>
>> This is hard to get around correctly and the reason for this setup  
>> to be
>> so unpopular securitywise.
>>
> That's a good point for a general-purpose wiki tool. Thanks for  
> pointing
> that out.
>
> It's not quite so relevant for the specific use we are making of
> JspWiki, and not at all an issue for development/testing. But I agree
> that *most* people won't be using jspwiki the way we do.
>
> Just for the record (in case someone else wants to do this), enabling
> "url rewriting" support seems to be fairly easy. I have:
> * added a servlet filter which stores the HttpServletResponse in a
> thread-local
> * implemented a custom URLConstructor (subclassing
> DefaultURLConstructor) which overrides the makeURL method to fetch the
> HttpServletResponse from that thread-local and invoke encodeURL on it.
> Note that this method is also called during jspwiki startup, so a null
> HttpServletResponse needs to be ignored.
>
> I'm not sure if this approach will fix 100% of the urls that JspWiki
> generates, but it is certainly enough to get things generally  
> working in
> our test environment (so far).
>
> Regards,
> Simon
>