incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@mac.com>
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 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
>


Mime
View raw message