Strange behaviour of URL without slash

[sdm]

If you browse to ​http://localhost:8888/myappabc, the same page is called as when you'd browse to ​http://localhost:8888/myapp/abc (I'm using JAX RS).

The difference is that when you're not logged in while browsing to ​http://localhost:8888/myappabc, you're not redirected to the login page. The abc page is shown, but all the secured content on the page is left out.

[sdm]

The problem I described in this issue can be reproduced in the kauri-routing-sample:
When you browse to ​http://localhost:8888/jaxrs/vegetable, you see an XML result (a list of vegetables) on the page. Now try to browse to ​http://localhost:8888/jaxrsvegetable and see that the same result is returned.

This starts getting problematic when security is involved, as I also described briefly in this issue.

I'll try to explain the problem a bit more accurate:
The page ​http://localhost:8888/myapp/abc I was talking about is a secured page in auth.xml: so when you're not logged in, you should not get access to this page. When you browse to ​http://localhost:8888/myappabc without being logged in, this secured page IS shown, but if this page contains references to other secured content, for example, a form getting its content from another secured URI, for example ​http://localhost:8888/myapp/persons/2, then that content is obviously not shown because the URI is correctly protected in auth.xml. But when you then manually browse to ​http://localhost:8888/myapppersons/2 (without the slash) without being logged in, then the content that corresponds with myapp/persons/2 is shown, even though the page myapp/persons/ is a protected page!

I hope my further explanation solved the confusion about this issue, if not, feel free to ask some more details.

[jgou]

It seems to be a JAX-RS issue, and not a bug in the kauri routing itself.
Would be minor, if not for the security concerns.

[jgou]

Actually, I'm not sure this is even a bug.
The jaxrs configuration in router.groovy has a uri parameter with wich you can configure where to mount the jaxrs resources:

jaxRs(uri: "foo") {
  jaxRsResource(scanPackages: "*")
  jaxRsProvider(scanPackages: "*")
}

Since this has to match e.g. the path "foo/bar" , the "starts-with" matcher is used. This means however that "foobar" will also match the above uritemplate. Then "foo" is set as base path so the jaxrs implementation will look for resources matching "bar" in both cases.
You can easily avoid the second match, by using uri="foo/" (add slash at the end) instead of "foo".

So maybe this needs documentation rather than fixing ?

[freya]

+1

[jgou]

documented in 164-kauri