Reinstall not possible due to 401

Jira Development Jira Cloud
, , ,
#1

Hi everyone,
We encountered this problem during the last weeks.

The use case is:
Customer has installed the addon, then uninstalled it. Once the customer tries to install it again (from marketplace) - the 401 error occur.

image
image1332Ɨ419 20.9 KB

From the last version of the addon we started to use atlassian-connect-spring-boot library for authentication (JWT Bearer token).
First install works, reinstall fails with 401 HTTP code.

We found out that:

  • After we remove the record in the database, installation is possible again.
  • Shared_secred column from the database is the same for all records
  • Created_date and Last_modified_date has same values for a record
  • Addon_installed fields is always with ā€˜TRUEā€™ value even if the user has uninstalled it

Has anyone encountered this kind of problem? What are the options to debug and learn more.
Thanks in advance.

Kind Regards,
Philip Kasapov

2 Likes
#2

@fkasapov, did you find corresponding entries in your Spring application log?

#3

Hi, @epehrson,
Thank you for your response.
Here are some lines from ā€œlocalhost_access_log.2018-10-09.txtā€ exactly at the time, when we are trying to perform this case.

    • [09/Oct/2018:12:39:36 +0000] ā€œPOST /pmaddon-a//uninstalled?user_key=admin HTTP/1.1ā€ 401 118

ā€¦

    • [09/Oct/2018:12:40:38 +0000] ā€œPOST /pmaddon-a//installed?user_key=admin HTTP/1.1ā€ 401 118

ā€œcatalina.outā€ seems to be okay. If any further information is needed, let me know.

Thanks,
Philip

1 Like
#4

Itā€™s me again.
@epehrson here is some additional information from our logs.

2018-10-15 13:08:43.447 DEBUG 25265 --- [nio-8009-exec-5] c.a.c.s.i.a.jwt.JwtAuthenticationFilter  : Retrieved JWT from request
2018-10-15 13:08:43.447 DEBUG 25265 --- [nio-8009-exec-5] c.a.c.s.i.a.j.JwtAuthenticationProvider  : Parsed JWT: {"sub":"aioceva","qsh":"bf0a73c10f0537de9a5b967e4e645b90828e679f2163d5abc47522fd000a736e","iss":"jira:0cc74e54-751f-4098-a0bc-5ade24f11760","context":{"user":{"accountId":"557058:12322b13-7665-465d-83df-198128e58f10","displayName":"Annie Ioceva","userKey":"aioceva","username":"aioceva"}},"exp":1539609822,"iat":1539608922}
2018-10-15 13:08:43.451 DEBUG 25265 --- [nio-8009-exec-5] c.a.c.s.i.a.j.JwtAuthenticationProvider  : Canonical request for incoming JWT: CanonicalHttpServletRequest[method=POST,relativePath=//installed,parameterMap=[user_key -> (aioceva),]]
2018-10-15 13:08:43.452 ERROR 25265 --- [nio-8009-exec-5] c.a.c.s.i.a.j.JwtAuthenticationProvider  : Expecting claim 'qsh' to have value 'aa3589ea5bc4a539e1da2596bd46c517ac8a66fd78b35919b09e0177641c1e09' but instead it has the value 'bf0a73c10f0537de9a5b967e4e645b90828e679f2163d5abc47522fd000a736e'
2018-10-15 13:08:43.453 DEBUG 25265 --- [nio-8009-exec-5] .s.i.l.LifecycleControllerHandlerMapping : Looking up handler method for path /error
2018-10-15 13:08:43.453 DEBUG 25265 --- [nio-8009-exec-5] .s.i.l.LifecycleControllerHandlerMapping : Did not find handler method for [/error]

Thank you in advance.
Philip

#5

@fksasapov,

The qsh is the Query String Hash that ensures the request came from the source we expect and the values arenā€™t being tampered with en route.

The error you are getting states that the expected hash based on the values expected donā€™t match the hash that was received and thus either the hash isnā€™t being calculated correctly or the values are not coming from the source.

Can you tell us a little more about how your app is set up? Is there proxy or firewall in between Jira Cloud and your app? Have you tried to create the qsh manually to see where the problem might be occuring?

#6

@rwhitbeck,

We are currently using 2 EC2 instances in AWS. One is with Apache installed and the other one is hosting the app. Apache is rewriting all http requests to https and forwarding via proxypass to ajp://:8009/context. The descriptor is accessible, hosted under Tomcat 8. Apache is forwarding via public ip addresses at that point. There are no firewall or security group outside of default values, nothing specifically configured. Also, we havenā€™t tried to create qsh manually.

Regards,
Philip

#7

We moved the plugin in a container and pointed the apache to the container public ip address. This solved all problems except updating old version to new version without removing the line from the DB. It seems it is not present in the new version so we will probably leave it that way.