Uploaded image for project: 'FishEye'
  1. FishEye
  2. FE-5364

2LOi requests made from an application that has the username in a different case than FishEye/Crucible aren't authenticated properly even if 'force lowercase' is set

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 3.8.1, 3.9.0
    • 2.2.0, 3.6.4
    • None

      The implementation of com.atlassian.sal.api.user.UserManager#resolve, doesn't consider the 'force lowercase'
      setting when processing the username provided in the 2LO request. This will cause the request to continue being processed as anonymous (as the 2lo validation succeeds, but it didn't have a valid username).

      This potentially affects other auth methods that try to resolve a username (like trusted apps). 3LO is not affected, as the exact-cased username is stored with the 3LO token when creating the token.

      Effects of this might include requests made from other applications with such a configuration to be treated as anonymous requests, and show incomplete or no data, depending on the request type and Fisheye's configuration.

      A workaround is to use 3-legged OAuth for such configurations.

          Form Name

            [FE-5364] 2LOi requests made from an application that has the username in a different case than FishEye/Crucible aren't authenticated properly even if 'force lowercase' is set

            Antonio Cerezo Iglesias added a comment -

            Great news! Thank you for the update!

            For now we've applied the suggested workaround and it works.

            Thanks and regards,
            Antonio

            Antonio Cerezo Iglesias added a comment - Great news! Thank you for the update! For now we've applied the suggested workaround and it works. Thanks and regards, Antonio

            Lukasz Pater added a comment -

            This will be included in the upcoming 3.8.1 release

            Lukasz Pater added a comment - This will be included in the upcoming 3.8.1 release

            Lukasz Pater added a comment -

            acerezo - this issue is high on our priority list, and we're focusing to get it resolved as soon as possible. Unfortunately I can't promise a specific date or release that the fix will be included in at the moment.

            Looking at the issue, I believe just enabling non-impersonating 2-legged OAuth (keeping 'Allow user impersonation through 2-legged OAuth' setting disabled), should work around the issue, and allow you to see the development panel.

            Lukasz Pater added a comment - acerezo - this issue is high on our priority list, and we're focusing to get it resolved as soon as possible. Unfortunately I can't promise a specific date or release that the fix will be included in at the moment. Looking at the issue, I believe just enabling non-impersonating 2-legged OAuth (keeping 'Allow user impersonation through 2-legged OAuth' setting disabled), should work around the issue, and allow you to see the development panel.

            Antonio Cerezo Iglesias added a comment -

            Hi Lukasz,

            Using 3LO makes the Development panel, or at least the part referring to FishEye commits or pull requests, disappear just after the ticket loads.

            Is there an estimate of when this bug is going to be addressed?

            Thanks and regards,
            Antonio

            Antonio Cerezo Iglesias added a comment - Hi Lukasz, Using 3LO makes the Development panel, or at least the part referring to FishEye commits or pull requests, disappear just after the ticket loads. Is there an estimate of when this bug is going to be addressed? Thanks and regards, Antonio

              lpater Lukasz Pater
              lpater Lukasz Pater
              Affected customers:
              2 This affects my team
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: