nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira tasks from Confluence are not visible after directory change

Кирилл Самсонов

Previously, we used Jira accounts in the Jira Internal Directory, but due to security issues, we had to change them to domain accounts. Since mass transfer was not possible, the scheme was used:

1. A new "user-new" entry was created for the "user" in the new directory

2. It indicated the same groups as the old user.

3. All tasks of the old user were transferred to the new one.

4. The old account was renamed to "user_old", the new one to "user"

After that, there was a problem that when using Confluence, no tasks from Jira became visible. The error text "the Jira problem does not exist, or there are insufficient rights to view it" and "The Jira links could not be displayed. Perhaps the problem does not exist, or there are not enough rights to view it"

At the same time, the accounts have an absolutely identical set of rights and groups. The problem is relevant for all migrated accounts

Accepted answers

All comments

Radek Dostál

Application Links use OAuth, more on that here: https://confluence.atlassian.com/adminjiraserver0813/using-applinks-to-link-to-other-applications-1027137531.html

Have you only changed the accounts in Jira, or also Confluence?

Can you show us the application link setup from both applications? (You can obfuscate urls or ids, just want to see the settings.)

Lastly, can you tail atlassian-confluence.log, load a page resulting in the error, and see if it throws anything in the log? If the problem is what I think it is, there should be a stacktrace in there. I'd expect one of these errors https://confluence.atlassian.com/kb/oauth-troubleshooting-guide-719095274.html#OAuthTroubleshootingGuide-Errormessagesinthelogs

And finally, if you try to create a new 'jiraissue' macro - does it work? Does it let you authorize the AppLink, or does it simply throw an error with no authroization prompt at all?

Кирилл Самсонов

We changed accounts in jira and then they migrated to confluence

2022-03-23 12_37_36-Window.png 2022-03-23 12_36_23-Window.png

I looked atlassian-confluence.log, but I didn't find any mention of the problem there. I didn't even find a mention of the user at the time when he had an error

Radek Dostál

Thanks, this narrows things down a little bit. So as far as I know this should mean that Confluence keeps 'oauth' tokens in it's database for each user. My suspicion is that the tokens are now stale because they are - for the lack of better words - using "user_old" Jira counterparts.

We changed accounts in jira and then they migrated to confluence

Could you elaborate what this means?

Here's my theory, previously you would have username "bob" in Confluence, with his "bob" username in Jira.

Bob logs into Confluence for the first time, and then sees a macro from Jira with "Authorize" prompt.

Bob clicks it, logs into Jira, thus Confluence stores a token for Bob.

This token will be used to fetch Jira data under the account Bob logged into Jira with.

Later, Jira username "bob" was changed to "bob_old" - this technically did not invalidate the token in Confluence, rather, Confluence is still trying to use this token, but Jira is (rightfully so) saying "sorry but you no longer have access to this resource, according to your account bob_old".

And there we are getting to the "but hey, same username!?", well, I would assume the tokens are stored on a "userkey" basis (and I mean, userkey is basically the same as account id as far as uniqueness goes). So even though you created the same username "bob", it's unique userkey is different. They are entirely different user accounts to Jira after all.

Does this sound like this could be the case so far? Because if so, then I think you would need to manually remove all OAuth tokens from Confluence DB (there is an sql query to delete them), and then each user would have to authorize their AppLink again to re-create the OAuth token. Only this time, it would use their "new" Jira accounts.

This of course is not ideal since you would want to shutdown, backup, delete, start, and then the users would be inconvenienced to authorize the app link.

However, in the case that you have also switched Confluence user directory to ldap, and you now have exactly the same user directory, thus exactly the same userbase, then you might be able to switch to OAuth with Impersonation - which should, in theory, not require the users to authorize the AppLink connection - the macros should work for them, provided they have the same username in both Confluence and Jira.

I'm also curious right now if there is a way to confirm the OAuth token theory on a local scale (e.g. just 1 user) before deciding to do the big bang. There must be a way to link the token back to the Confluence user, so you should be able to find just the one token for e.g. your user, try to delete it, and then see if Confluence asks you to re-authorize and if things will work.

The sad part is I don't have a single instance which doesn't use OAuth with Impersonation already (have been around impersonation for years now..), so I can't test this or look around the db myself, or try to simulate your situation to confirm my idea.

Кирилл Самсонов

Could you elaborate what this means?

Maybe I wrote incorrectly, but I wanted to say that we only worked with Jira users

Yes, I also had a theory, the same as you

I will try to remove the OAuth token in the Conf database from one user and then write here about the results

Кирилл Самсонов

I removed the old user's access from Conf to Jira, after that the new user had a request for authentication from Conf to Jira and after that the problem disappeared! The last question is how to do it massively for old users now

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

server

jira-software

jira-software-server