Failure to authenticate against JIRA 7.2.1
Every attempt to authenticate against a JIRA instance running version 7.2.1 fails with code 401. Same exact setup with version 7.9.x works. Is 7.2.1 supported?
Comments (19)
-
-
-
assigned issue to
-
assigned issue to
-
Hello Mike,
Just checked on my side and it works.
Most likely issue relates to the license (absent, invalid, outdated).
Could you open personal profile page ({base_url}/secure/ViewProfile.jspa) and check if there is such error message:
Additionally, plugin write following message in the log file:
2020-02-20 10:07:56,552 http-nio-2990-exec-1 WARN anonymous 607x36182x1 - 0:0:0:0:0:0:0:1 /rest/api/latest/configuration [c.w.j.tokens.filters.TokenFilter] User admin(admin) cannot use
API Token. License for API Tokens plugin is not valid
Looking forward to your answer,
Roman
-
Hi Roman,
Checked the license - it’s valid, installed. What’s even stranger is that the token access timestamp is updated, even though I still get a 401. I do not see any messages from the plugin in the logs, this is the only message that I see at the time of access:
2020-02-20 07:15:36,345 http-nio-127.0.0.1-8080-exec-24 anonymous 435x1058020x1 - 192.168.237.76,127.0.0.1 /rest/api/latest/configuration HttpSession created [1fdvbze]
-
Interesting!
That means the plugin seems to be working well. After passing token check request goes to the standard permission check.So assumption is that Jira gives that response.
Could you please check same request but using password instead of token?
Expected result: 401 Unauthorized
Which means lack of permissions for that particular user and particular resource.
Additionally, you can increase log level:
{base_url}/secure/admin/ViewLogging.jspa > Configure > com.wombatscorp.jira.tokens | DEBUG > Add
Then make request once more and check logs.
Regards, Roman
-
Tried the same request with a password instead of the token and got a valid response
$ curl -s --user mike.reznik:$JIRA_API_TOKEN https://jira/rest/api/latest/configuration
{"errorMessages":["You are not authenticated. Authentication required to perform this operation."],"errors":{}}
curl -s --user mike.reznik https://jira/rest/api/latest/configuration
Enter host password for user 'mike.reznik':
{"votingEnabled":false,"watchingEnabled":true,"unassignedIssuesAllowed":true,"subTasksEnabled":true,"issueLinkingEnabled":true,"timeTrackingEnabled":true,"attachmentsEnabled":true,"timeTrackingConfiguration":{"workingHoursPerDay":8.0,"workingDaysPerWeek":5.0,"timeFormat":"pretty","defaultUnit":"hour"}}
Enabling DEBUG logging provided new information. It looks like Token Auth passes, but then I somehow get a 401 anyway?
2020-02-20 10:58:16,521 http-nio-127.0.0.1-8080-exec-4 DEBUG anonymous 658x1098614x1 - 192.168.237.76,127.0.0.1 /rest/api/latest/configuration [c.w.j.tokens.filters.TokenFilter] User:mike.reznik(mike.reznik)
2020-02-20 10:58:16,753 http-nio-127.0.0.1-8080-exec-4 anonymous 658x1098614x1 - 192.168.237.76,127.0.0.1 /rest/api/latest/configuration HttpSession created [1xkrwm8]
2020-02-20 10:58:16,754 http-nio-127.0.0.1-8080-exec-4 INFO mike.reznik 658x1098614x1 - 192.168.237.76,127.0.0.1 /rest/api/latest/configuration [c.w.j.tokens.filters.TokenFilter] mike.reznik(mike.reznik) has been authenticated via API Token (asp_Sz6zNcNEphxYHSN2)
2020-02-20 10:58:16,754 http-nio-127.0.0.1-8080-exec-4 DEBUG mike.reznik 658x1098614x1 - 192.168.237.76,127.0.0.1 /rest/api/latest/configuration [c.w.j.tokens.filters.TokenFilter] StartTime '2020-02-20 10:58:16.754' RequestURI '/rest/api/latest/configuration' QueryString 'null' User 'mike.reznik'
-
I’m impressed. May ask you about one more thing: check same in the Safe Mode with only this plugin enabled
{base_url}/plugins/servlet/upm/manage/user-installed
-
Unfortunately, this is a production instance and I cannot put it into Safe Mode right now. I will schedule a maintenance window for it, but it might take me a couple of days to get one.
Are you aware of any specific plugins there could be a conflict with? I can check and see if we have those.
-
There was two different issues related to plugins conflict, so I’m just asking to be sure.
If it needs a maintenance schedule I can check that on my side.
Could you please send to info@wombatscorp.com result of following request:
{base_url}/rest/plugins/1.0/
I will try to install all your plugins with appropriate versions and reproduce the issue.
-
- attached jira-plugins.json
Attaching output
-
Hi @Mike Reznik
I’ve checked on my side with installing all your plugins with appropriate versions, but, was not able to reproduce.
However, It still doesn't mean that other plugin not affect functionality.
I have got an idea about some improvement and will come back in several days a with new version to you.
But may I ask you to check Safe Mode as an additional task on your next maintenance window? No need in downtime just because of this.
Regards, Roman
-
Thanks Roman!
I am trying to get a maintenance outage on the schedule for this week, will report back as soon as I can try Safe Mode
-
- attached jira-tokens-1.1.4.jar
Hi @Mike Reznik could you please check attached release candidate for v1.1.4 JAR?
I have improved authentication process and hope it will help with your issue
-
Hi Roman,
I installed the updated version, tried starting it, and got the following errors
2020-03-02 18:04:33,459 ThreadPoolAsyncTaskExecutor::Thread 28 ERROR mike.reznik 1084x526056x5 1u0nfzy 192.168.237.114,127.0.0.1 /rest/plugins/1.0/com.wombatscorp.jira-tokens-key [c.a.p.osgi.factory.OsgiPlugin] Unable to start the plugin container for plugin 'com.wombatscorp.jira-tokens'
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'tokenFilter': Unsatisfied dependency expressed through constructor argument with index 4 of type [com.atlassian.event.api.EventPublisher]: : No qualifying bean of type [com.atlassian.event.api.EventPublisher] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {}; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [com.atlassian.event.api.EventPublisher] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {}
2020-03-02 18:04:43,469 ThreadPoolAsyncTaskExecutor::Thread 28 ERROR mike.reznik 1084x526056x5 1u0nfzy 192.168.237.114,127.0.0.1 /rest/plugins/1.0/com.wombatscorp.jira-tokens-key [o.e.g.b.e.i.util.concurrent.RunnableTimedExecution] Closing runnable for context NonValidatingOsgiBundleXmlApplicationContext(bundle=com.wombatscorp.jira-tokens, config=osgibundle:/META-INF/spring/*.xml) did not finish in 10000ms; consider taking a snapshot and then shutdown the VM in case the thread still hangs
-
- attached jira-tokens-1.1.4.1.jar
Okay
I removed part that cause last issue and will investigate it deeply, but could you please check once more
-
Version 1.1.4.1 installed and enabled successfully. However, the original problem remains. Confirmed via DEBUG logging.
-
It surprised me once more. In the last update plugin fully mimic out-of-the-box authorization and there shouldn’t be any differentiation for the system.
As it is not reproducible on my own I would rather wait until Safe Mode testing results.
However, I will keep thinking about other approaches to get the root cause.
Thank you, Mike, for your patient
-
- attached jira-tokens-1.1.4-trace.jar
Hi Mike,
I have got an idea how to find the root cause!
Patched plugin jira-tokens-1.1.4-trace.jar includes an additional diagnostic to print stacktrace on Response change.
For instance, when any code after auth with token will decide to change the status to 401 stacktrace will appear in the logs.
It requires TRACE log level for com.wombatscorp.jira.tokens
I’m eager to receive your logs, Roman
-
- changed status to on hold
- Log in to comment
Apparently I wasn’t logged in when submitting an issue