Hi Wicketeers,

My client has a web security infrastructure in place where a transparent
proxy sits in front of the application server and filters requests based
on URL pattern. I am trying to fit their first Wicket-based application
into this infrastructure. We would like to allow requests based on URL
pattern and authentication level and block all unrecognized requests.

I'm using HybridUrlCodingStrategy to try and preserve the mount point
in subsequent links and form URLs. This works well in some cases, but
falls down when I pass parameters to a page. For example, a page mounted
on "mypage" with no parameters results in a URL like this...

  http://host/myapp/mypage

...and links on the page are rendered like this...

  ?:wicket:interface:...

...which the browser recognizes as something like this...

  http://host/myapp/mypage.4?:wicket:interface:...

...which is great, since we can still implement our security policy
based on the "mypage" portion of the URL. The problem is, if I pass a
parameter to the page, the URL looks like this...

  http://host/myapp/mypage/key/value/

...and links on the page look like this...

  ../../../?:wicket:interface:...
  
...which the browser reduces to this...

  http://host/myapp/?:wicket:interface:...

This is no longer good, because we've lost the mount point. The problem
appears to be the trailing slash added by
AbstractRequestTargetUrlCodingStrategy.appendValue, which triggers an
extra "../" to be added to the link URL. And if the mount point as a
slash inside it, e.g. "foo/bar", then neither case works properly.

It's starting to feel that it will be difficult to preserve the mount
point across requests. I know this has been discussed before on this
list, usually in the context of "pretty" URLs, but I haven't seen a good
solution. Has anyone been able to get something like this to work well?

jk


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to