Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-31932

Getting 401 Unauthorized error in console when clicking "Can't access your account?" link

      Steps to reproduce this problem
      1. Click on the link "Can't access your account?".
      2. Open developers tools and saw the error:
        GET http://localhost:8080/rest/helptips/1.0/tips 401 (Unauthorized)
        
      3. Occur in web browser Google Chrome v25 and FF 19 but not IE9.

            [JRASERVER-31932] Getting 401 Unauthorized error in console when clicking "Can't access your account?" link

            Hi all,

            An update on this issue. Testing against JIRA 6.4 we were no longer able to reproduce this issue. It should not be an issue for version 6.4 onwards.

            Regards,
            Rob Chatfield
            [Atlassian]

            Robert Chatfield added a comment - Hi all, An update on this issue. Testing against JIRA 6.4 we were no longer able to reproduce this issue. It should not be an issue for version 6.4 onwards. Regards, Rob Chatfield [Atlassian]

            HI msymons

            We understand that this is an important issue causing pain for your organization and use case at the moment.

            However, the priority field is set strictly according to the criteria set at https://jira.atlassian.com/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels and I do this myself personally for each new issue that gets created in this site as part of the process of triaging incoming issues on a daily basis.

            It is important for us to be strict about the priority definition as, otherwise the value of the field would stop being a useful information tool for prioritising fixes.

            Having said this, there's many other factors involved in scheduling a bug for fixing besides the value of the Priority field. Customer interest, votes, supportability impact amongst many others come into play when selecting bugs for our backlog and the Priority field is only one of the things we take into account when doing so.

            Please do watch the issue, I will update it as soon as new information is available about its status.

            Hope the information sheds some light into this and helps.

            Regards,

            Oswaldo Hernández.
            JIRA Bugmaster.
            [Atlassian].

            Oswaldo Hernandez (Inactive) added a comment - - edited HI msymons We understand that this is an important issue causing pain for your organization and use case at the moment. However, the priority field is set strictly according to the criteria set at https://jira.atlassian.com/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels and I do this myself personally for each new issue that gets created in this site as part of the process of triaging incoming issues on a daily basis. It is important for us to be strict about the priority definition as, otherwise the value of the field would stop being a useful information tool for prioritising fixes. Having said this, there's many other factors involved in scheduling a bug for fixing besides the value of the Priority field. Customer interest, votes, supportability impact amongst many others come into play when selecting bugs for our backlog and the Priority field is only one of the things we take into account when doing so. Please do watch the issue, I will update it as soon as new information is available about its status. Hope the information sheds some light into this and helps. Regards, Oswaldo Hernández. JIRA Bugmaster. [Atlassian] .

            Please escalate the priority of this defect. Whilst it's not something that has visibility to the user, that should not be used as an excuse to do nothing about it. This (and many other similar defects) spam the logs to such an extent that it becomes really hard to spot the problems that really need looking at. This increases the total cost of ownership of JIRA.

            The workaround does instantly get rid of the HTTP 401 reported in the JIRA access logs.... but it causes new errors to appear in atlassian-jira.log

            2014-02-19 09:59:02,069 http-bio-8080-exec-15 WARN userx 599x64844x1 19qyfkl xxx.xxx.xxx.xxx /browse/yyy-1464 [atlassian.plugin.webresource.DefaultResourceDependencyResolver] Cannot include disabled web resource module: com.atlassian.plugins.helptips.jira-help-tips:common
            

            Thousands upon thousands of such WARN events every day.

            This is seen with v0.31 of the plugin, used in JIRA v6.0.8
            This is seen with v0.44 of the plugin, used in JIRA v6.1.7 and also in JIRA v6.2 Beta-1.

            Mark Symons added a comment - Please escalate the priority of this defect. Whilst it's not something that has visibility to the user, that should not be used as an excuse to do nothing about it. This (and many other similar defects) spam the logs to such an extent that it becomes really hard to spot the problems that really need looking at. This increases the total cost of ownership of JIRA. The workaround does instantly get rid of the HTTP 401 reported in the JIRA access logs.... but it causes new errors to appear in atlassian-jira.log 2014-02-19 09:59:02,069 http-bio-8080-exec-15 WARN userx 599x64844x1 19qyfkl xxx.xxx.xxx.xxx /browse/yyy-1464 [atlassian.plugin.webresource.DefaultResourceDependencyResolver] Cannot include disabled web resource module: com.atlassian.plugins.helptips.jira-help-tips:common Thousands upon thousands of such WARN events every day. This is seen with v0.31 of the plugin, used in JIRA v6.0.8 This is seen with v0.44 of the plugin, used in JIRA v6.1.7 and also in JIRA v6.2 Beta-1.

              Unassigned Unassigned
              ckimloong John Chin
              Affected customers:
              13 This affects my team
              Watchers:
              17 Start watching this issue

                Created:
                Updated:
                Resolved: