change the coding strategy to use query string to encode params. see querystringcodingstrategy for necessary code.
-igor On Fri, Jan 9, 2009 at 6:36 AM, John Krasnay <j...@krasnay.ca> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
