Page MenuHomePhabricator
Create Task
Maniphest T4289

JIRA authenticator JIRA version 5 compatibility
Closed, WontfixPublic
Actions

Description

We are using JIRA 5. As on the frontend there is no mention of requirements, I tried to use the JIRA authenticator to allow users to register and log in with their JIRA accounts.

However, this fails on retrieving the account ID from the user info.

The cause of this is that as the account ID the JIRA users 'key' is used - which was introduced in JIRA 6 (to allow user renaming).
The corresponding line of the authenticator logic:
https://secure.phabricator.com/diffusion/PHU/browse/master/src/auth/PhutilAuthAdapterOAuthJIRA.php;1aa6299fcdfb31e9572d054c01afbc078b70fd7d$27

A workaround that seemed to work for us is to just use 'name' rather than 'key'.
However, one has to be aware of a migration strategy as with JIRA 6 you would want to use the key. With a manually triggered migration of the user data, getting a user by (account) name and then saving the key as the new oauth id should be sufficient.

Maybe the authenticator could be adjusted to support JIRA 5 as well as 6 at the same time?
Or maybe two authenticators could be provided, one for JIRA 5 and one for JIRA 6?

Revisions and Commits

rP Phabricator
D7906rP3524ba3fb56a Add warnings to JIRA auth provider that we only support JIRA 6

Related Objects
Search...

Event Timeline

ite-klass created this task.Jan 8 2014, 12:14 PM
ite-klass raised the priority of this task from to Needs Triage.
ite-klass updated the task description. (Show Details)
ite-klass added a project: Auth.
ite-klass added a subscriber: ite-klass.
epriestley added a subscriber: epriestley.Jan 8 2014, 1:59 PM

Ugh, this is messy. At a minimum, we should document that we only support JIRA 6 right now.

Providing an upgrade path here seems really tricky. In theory, I think we can do it automatically and get it right in most cases, but the auth infrastructure generally assumes that remote systems give us an immutable, unique, permanent identifier for each account, so it doesn't support any workflows like "try all these different types of identifiers and see if there's a match".

ite-klass added a comment.Jan 8 2014, 2:04 PM

I guess that would be an argument for two authenticators.
For JIRA 5 the name is the unique key, for JIRA 6 key is the unique key.
That would not provide a migration path, but make their independence and incompatibility (more) clear I guess.

epriestley edited this Maniphest Task.Jan 8 2014, 2:06 PM
epriestley triaged this task as Wishlist priority.Jan 8 2014, 2:24 PM

I'd like to support both, and provide a clean and upgrade path between them. Particularly, supporting JIRA 5 as a second provider tends to make it very difficult to ever upgrade cleanly.

I suspect it's not a huge amount of work to do this in a clean way. We can introduce some "try all these different identifiers" code, or add some kind of secondary/fallback identifier (and hope we never have a provider with three different identifiers). This is probably not a huge amount of code, and all other providers can easily ignore it, so it doesn't create any systemic fragility.

However, it's really messy to develop and test, since we have to install JIRA 5 and them upgrade it to JIRA 6 every time we want to check that the code works. Since there hasn't been much other interest in JIRA 5 support, this is going to be hard to prioritize. You can see T3179 for some limited discussion of similar issues.

You could work around this by maintaining a local patch to use name, or copy/pasting the JIRA provider and config to create a JIRA5 provider (you can drop your new copies in phabricator/src/extensions/ and Phabricator should pick them up at runtime). Either approach here will make any migration support we eventually provide not work, but if you're comfortable poking around a bit it should be reasonably easy to migrate manually when the time comes, provided you can pull a name -> key mapping out of JIRA.

D7906 should make this limitation more clear in the UI, at least.

ite-klass added a comment.Jan 8 2014, 2:43 PM

Thank you for the fast response and handling!

epriestley edited this Maniphest Task.Jan 8 2014, 5:43 PM
hartman added a subscriber: hartman.May 22 2014, 12:20 PM

This actually makes it difficult for me to migrate away from JIRA :(

Now I need to get everyone on board and make a full transition to Phabricator, whereas I was hoping to show everyone the wonder of Phabricator with existing JIRA5 and slowly onboard everyone.

Is there a chance that I can at least get "phabricator:jira-issues" exposed without using JIRA auth ? Or any workaround to define custom commit message fields or links inside commit messages ?

ite-klass added a comment.Jun 5 2014, 6:58 AM

If you migrate from JIRA5 and thus never want to use JIRA6, you can patch Phabricator (libphutil) without the dangerous consequences you would otherwise have when upgrading JIRA later on. (The mentioned workaround above.)

In libphutil/src/auth/PhutilAuthAdapterOAuthJIRA.php in getAccountID() change key to name.

hartman added a comment.Jun 5 2014, 1:11 PM

So in terms of migration, would it not be possible to split the auth provider in two (JIRA5 and JIRA6) and just let users re-couple their accounts in case of a JIRA5 to JIRA6 upgrade ? We use LDAP auth as primary auth methodology anyways.

epriestley added a comment.Jun 5 2014, 4:22 PM

It would be possible, but very inconvenient for users.

In cases where an install uses JIRA as the primary auth, you would need to have both JIRA 5 and JIRA 6 running at the same time in order to be able to have users log in (with JIRA 5) then connect to JIRA 6, or do something like "everyone log in; don't log out!!!; turn off jira 5; turn on jira 6; link accounts".

epriestley edited this Maniphest Task.Jun 19 2014, 9:13 PM
turadg mentioned this in T5422: Does Phabricator integrate with JIRA?.Jan 2 2015, 8:44 PM
epriestley mentioned this in T7732: Convoluted flow when locked out of account with only one auth provider.Apr 11 2015, 3:31 PM
epriestley moved this task from Backlog to JIRA is Special Too on the Auth board.Feb 5 2019, 2:07 PM
epriestley closed this task as Wontfix.Feb 24 2020, 9:10 PM
epriestley claimed this task.

JIRA did this (changed how accounts are identified) again recently (key is now accountId), see T13493.

As part of the response to T13493, I've added "try all these different identifiers" code. At time of writing, we try key and accountId.

It's possible that we could support JIRA5 by also trying name, but this task is very old and I'm not directly aware of any customers using JIRA5 today. For now, I'm going to "Wontfix" this under the assumption that everyone may reasonably be on JIRA6 or newer by now.

If you're a customer who still runs JIRA5 and remain interested in support for JIRA5, feel free to open an issue through your support channel. This may be a 4-line fix, as long as we don't worry too much about what will happen when you upgrade to JIRA6+ in 2030.

Herald added a subscriber: amckinley. · View Herald TranscriptFeb 24 2020, 9:10 PM
Phabricator · Built by Phacility