incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching ...@ops.co.at>
Subject Re: url rewriting supported?
Date Thu, 19 Jun 2008 07:41:39 GMT
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


Mime
View raw message