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
