Open Alexander-Hjelm opened 2 years ago
@[royc75, We don't support instances where you are running MFA on your Jira Server, AFAIK. The password should be your JIRA Token, and you need to have the JIRA Server open to REST API calls, otherwise it will not work :)
@Alexander-Hjelm REST is open, I've confirmed on the Jira instance.
VS Code Atlassian extension uses that as well and it works for me there despite MFA being enabled with the same details (token as password).
@Alexander-Hjelm I have also tried with Jira admin user which has got access to everything, same error still. If that solution doesn't support MFA fair enough but most organisations use it these days.
Shouldn't matter. You can make REST API calls using username and the API token generated by the app. That will bypass the MFA.
-u is your full email and -p is the Jira access token you generated?
Check: https://github.com/solidify/jira-azuredevops-migrator/issues/535
Yes it is and as I said the exact same username and token works for other integrations but not for this one.
@Alexander-Hjelm Just tested with postman - Basic auth doesn't work, same 403, however using the token as a bearer token and I seem to get 200 OK back on /rest/api/3/field
Ah wait, it is taking me to the MS MFA login page :)
Yet again this seems to work just fine on VS Code but there I only set the personal access token it doesn't require the user
Could be something funky with CAPTCHA on the JIRA server side.
I know that you can set an optional SecurityProtocol here: https://github.com/solidify/jira-azuredevops-migrator/blob/master/src/WorkItemMigrator/JiraExport/JiraServiceWrapper.cs#L28. But we have never had the need to. MFA usually isn't a problem. You could maybe play around with that and see if you can get it working.
Tried to X-Atlassian-Token if that's what you mean, no luck but thanks....
BTW, we are using on prem Jira if it makes any difference and I've set "using-jira-cloud": false in the config.
No worries: We'll track this as a bug in case something fishy is going on, but can't say when we'll get back to it :)
In the meantime, a bypass solution could be to move a snapshot of your Jira Project to cloud with the Cloud Migration Assistant (https://confluence.atlassian.com/jirakb/how-to-migrate-a-project-from-jira-server-to-jira-cloud-779160760.html), and then use our tool to set up a migration job from Jira Cloud to ADO.
Thanks ! But we don't have Jira Cloud subscription :)
They have a free jira cloud plan now, I think. Don't know if it's relevant for you, but still an option :) https://support.atlassian.com/jira-cloud-administration/docs/what-is-the-free-jira-cloud-plan/
Works with Jira cloud so must be our setup :-/
@royc75, we have the option of authenticating via Oauth instead. Would such a solution work for you? and would it be possible for you to provide all the secrets and tokens as shown below:
@Alexander-Hjelm Afraid not, I'm not the master of my own domain in this organisation but thanks for the suggestion !
I'm still chasing the admins to advise as I believe it is due to policy / permissions in our Jira
@royc75 Ok! Let me know if you figure something out! I'll try to look into the issue as best I can in the meantime.
@Alexander-Hjelm The Jira team has created a service account for me which bypass MFA for SSO and it now works ! Unrelated question and apologise for hijacking this discussion for it: Is there a way to migrate work items such that Jira sprints mirror ADO iterations ?
@royc75 Ok, good to know! I'll recommend this as the first solution to try if anybody experiences the same problem again.
For the sprints, you will have to set the sprint-field
property in your config, and add a SprintMapper
. See this config for an example: https://github.com/solidify/jira-azuredevops-migrator/blob/master/docs/config.md
Thanks @Alexander-Hjelm I've got few other questions. Would it be possible to connect outside github please ?
Discussed in https://github.com/solidify/jira-azuredevops-migrator/discussions/583