-
Bug
-
Resolution: Duplicate
-
Medium
-
None
-
2.10.1
-
None
We're using Kerberos, and so the "/" is required to define the realm of our users.
However, when a user with a "/" in their username goes to create a personal space, they get a Confluence "page not found" page. For example, for a user name of "asdf/realm" would have this link to their personal space: https://bw-wiki.ncsa.uiuc.edu/display/~asdf/realm
If I manually point the browser to the correctly escaped link: "https://bw-wiki.ncsa.uiuc.edu/display/~asdf%2frealm" I get an apache "Not Found" error.
The link that is automatically generated by confluence is: https://bw-wiki.ncsa.uiuc.edu/display/~asdf%202frealm
Which is doubly escaping the "/", once to get to %2f, and then to %202f to escape the percent sign.
Please check where you're escaping your characters. Also, is it possible, even after proper escaping, to have a personal space for users with "/" in their usernames?
- duplicates
-
-
- Gathering Impact
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFSERVER-14696] Users with "/" in their names are unable to create personal spaces
Hi Josh,
We actually double URL encode the URL for a workaround for non ASCII characters in the username (they are decoded twice, once by the app server and once by us in the SimpleDisplayServlet ). Unfortunately this will result as /display/asdf/realm being interpreted as viewing the page realm in the space asfd There's no trivial workaround which wouldn't break it for some other sequence of characters, so I would suggest that either you try to find a way of renaming your users or modifying the URL generated for your users (this would require patching on your end, involving GeneralUtil.personalSpaceUrl and SimpleDisplayServlet which will map this URL back to an action ) .
A single encoded %2f would also give problems with Tomcat 6 .0.10 onwards:
Tomcat permits '\', '%2F' and '%5C' as path delimiters. When Tomcat is used behind a proxy (including, but not limited to, Apache HTTP server with mod_proxy and mod_jk) configured to
only proxy some contexts,
a HTTP request containing strings like "/\../" may allow attackers to work around the context restriction of the proxy, and access the non-proxied contexts.
The following Java system properties have been added to Tomcat to provide additional control of the handling of path delimiters in URLs (both options default to false):
* org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH: true|false
* org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH: true|false
Due to the impossibility to guarantee that all URLs are handled by Tomcat as they are in proxy servers, Tomcat should always be secured as if no proxy restricting context access was used.
Affects: 6.0.0-6.0.9
That may explain the apache "Not Found" error you are receiving.
Regards,
Andrew Lynch
closing as a duplicate of CONF-13479