incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: url rewriting supported?
Date Thu, 19 Jun 2008 19:39:06 GMT
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 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.


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

View raw message