Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-13479

Special characters eg. back slash, forward slash, plus sign in username breaks Personal Space

      A user is pulling down usernames from an LDAP and these usernames contain backslashes. This is all fine and good until the user creates a personal space. They can create these and edit the home page (at the time of creation), but after saving the home page the personal space is no longer accessible.

      username: US\someguy
      personal space created at: wiki/display/~us%5Csomeguy
      trying to access the personal space fails as the browser is bounced to wiki/display/us\someguy

      This also breaks if the username contains a forward slash or a plus sign, and probably various other special characters.

        1. People directory.jpg
          People directory.jpg
          112 kB
        2. Profile popup.jpg
          Profile popup.jpg
          7 kB

          Form Name

            [CONFSERVER-13479] Special characters eg. back slash, forward slash, plus sign in username breaks Personal Space

            Ian Wells added a comment -

            It is a bug to allow me to create an email address that Confluence can not handle.

            The issue is that Confluence personal space is not accessible after saving the homepage by using an Atlassian ID containing special characters such as back/forward slash and plus sign

            I created an atlassian account with email address of ian+tag@company.com

            But when I created pages under my confluence space, all links to these pages 404. I can no longer access the pages I created.

            if the email has a + in it, please give an error so I don't waste time trying to figure out why my confluence pages are broken.

            Note that I had to create a brand new Atlassian ID to workaround this problem and recreate from memory the Confluence pages I had created, because Atlassian does not allow me to change an email address.

            References:

            https://en.wikipedia.org/wiki/Email_address#Sub-addressing

            Note that using a + sign in an email address is a pretty standard way of tagging and/or aliasing email addresses.

            Ian Wells added a comment - It is a bug to allow me to create an email address that Confluence can not handle. The issue is that Confluence personal space is not accessible after saving the homepage by using an Atlassian ID containing special characters such as back/forward slash and plus sign I created an atlassian account with email address of ian+tag@company.com But when I created pages under my confluence space, all links to these pages 404. I can no longer access the pages I created. if the email has a + in it, please give an error so I don't waste time trying to figure out why my confluence pages are broken. Note that I had to create a brand new Atlassian ID to workaround this problem and recreate from memory the Confluence pages I had created, because Atlassian does not allow me to change an email address. References: https://en.wikipedia.org/wiki/Email_address#Sub-addressing Note that using a + sign in an email address is a pretty standard way of tagging and/or aliasing email addresses.

            Hi,

            Can we know the status on this bug as we are also facing the same issue with Confluence 5.8.13 . We are unable to start using Confluence.

            Omprakash Thamsetty added a comment - Hi, Can we know the status on this bug as we are also facing the same issue with Confluence 5.8.13 . We are unable to start using Confluence.

            This is a pop up we are getting on a user with "\".

            Jan Callewaert added a comment - This is a pop up we are getting on a user with "\".

            This bug also gives some very ugly behavior in the people directory. We get all messages "profile: No user <username without backslash>"

            Jan Callewaert added a comment - This bug also gives some very ugly behavior in the people directory. We get all messages "profile: No user <username without backslash>"

            Anatoli added a comment -

            A comment from Andrew from the duplicate case:

            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
            

            Anatoli added a comment - A comment from Andrew from the duplicate case: 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

              Unassigned Unassigned
              mtaylor@atlassian.com Maleko Taylor (Inactive)
              Affected customers:
              10 This affects my team
              Watchers:
              16 Start watching this issue

                Created:
                Updated: