I’m building an integration with Jira and I’m trying to retrieve which site was authenticated for on the screen. I can get a list of accessible resources using this endpoint, but it doesn’t contain details on which of those resources have been authenticated, so it’s unclear which cloud_id should be used to retrieve logs. I’m looking for and endpoint that returns the cloud_id for sites that have been authenticated. Help is greatly appreciated, thanks!
1 Like
All of those resources have been authorized. The endpoints involved in the 3LO flow do not return any information about which one was selected.
Thanks for the clarification, @ibuchanan. When we hit the /accessible_resources endpoint, we’re able to see all sites available even though they haven’t been authenticated. Is there an endpoint that will show us which sites have been authenticated? Is there a recommended approach to determining which endpoints have been authenticated? Currently, we’re making requests to each accessible resource and see which returns 200. Is there a better way to only make requests to sites that have been authenticated? Will be be rate limited for making requests to multiple sites, even if they result in 403 errors?
[
{
"id": "1234",
"url": "https://myurl.com", // user **did not** authenticate for this site, we are unable to get logs from this site.
"name": "test",
"scopes": [
"read:audit-log:confluence"
],
"avatarUrl": "test.png"
},
{
"id": "5678", // user **did** authenticate for this site, we want to make requests with this id
"url": "https://testsite2.com", // How can we tell this url was authorized for on the screen
"name": "test2",
"scopes": [
"read:audit-log:jira"
],
"avatarUrl": "test2.png"
}
}
]
Thank you, we really appreciate your help!
1 Like
I’m not entirely sure I understand your question. In part because you keep referring to “authenticated” sites. Do you mean “authorized”?
Assuming so, I’ve seen a few cases where developers have seen sites they did not realized had been authorized. However, if you start with a new client id & secret, and start with only the read:me scope, you’ll notice the array of accessible resources starts empty. The accessible resources array is intended to be the set of all sites for which the user authorized your app.
That said, I cannot explain why an authorized site would return a 403. Debugging this might require specific knowledge of your client id, secret, and some trace ids, in which case, you will need to open a developer support case so you could safely share those details with our engineers.
Thanks @ibuchanan, sorry for the confusion. When I say “authenticated”, I mean a user has gone through the OAuth flow for each site in the accessible_resources. That endpoint shows which sites are authorized for the app, but each site in the accessible resource array also needs someone to go through the OAuth flow. Is there an endpoint that shows which cloud id is authorized and authenticated? From what I’m seeing, the accessible_resources displays which sites can be authenticated, not which sites are authenticated.
Oh, interesting. If I understand correctly, you get the 403 when the user who performed the OAuth flow is not an admin? So, even if you ask for the read:audit-log:jira scope, that’s not a guarantee the user has the right permissions. To my knowledge, the “check for 403” logic is already optimal.
There endpoints you could use to interrogate the user’s permissions. For example, your client can get current user using GET /rest/api/3/myself with ?expand=groups,applicationRoles. However, that alone expands the scopes your app needs (read:jira-user) without actually fixing anything.
Perhaps the best error message you could provide is in the Jira Platform REST API docs:
Permissions required: Administer Jira global permission.
And if you propagate that message with links, that’s the best chance users will have to get an admin to perform the action.
As for “selecting a site”, I can only elaborate my initial response: there are no endpoints, payloads, or otherwise that will let your client ask which site was most recently selected during the OAuth 2 flow.
Thanks @ibuchanan, I appreciate your help!
Hi @ibuchanan , I am having the same issue of not being able to distinguish which option was selected on the authorization screen. I have to wonder what the purpose of the screen is if the 3rd-party integration cannot know which site was authorized… it isn’t a very good user experience to force the user to select the cloud site again within our app after they have done it on the authorization screen, but that seems to be our only option. I suggested here ( How to get site details authorized by a user during OAuth 2.0 3LO authorization step? - #4 by PerryTrinier ) that it would make sense to return the response of accessible-resources sorted by the most recently authorized. Does that sound reasonable or are there technical reasons why that would not be possible? How can I make a feature request?
Hi @PerryTrinier, we navigated the issue by making a request to every endpoint in accessible_resources. We determining which ones were authorized by seeing which endpoints returned 200 to eliminate the user having to select the site a second time. It’s not an ideal solution, but it works. Atlassian is working on a better solution here.
Edit: Sorry! I overlooked @andreapiazza’s post in which the problem has already been reported as ID-8490. Though I’m not sure I would characterize our status as “working on it”. Please watch, vote, and comment, so we can get some attention on it.
You are not alone. I have seen this quite a few times in the community. I recommend logging this problem as a suggestion (our term for “feature request”) so you, and others who might stumble upon this thread, would have something formal to track. Could you please open a “suggestion” issue yourself in our open Jira (JAC) in the ECO project ? The title of this thread is a pretty good summary. Once you have the issue key, please let us know here so other folks can watch, vote, and comment.
Datetime ordering might be a quick solution (and, to be clear, I’m nowhere close to that codebase). But I wouldn’t consider it very robust; it depends on implied synchronization, which could make testing & troubleshooting nearly imposssible. My recommendation (when I’ve had an opportunity to talk to the engineering team) would be to return the original state parameter in the accessible-resources. Although the spec has no accessible-resources concept, I think that’s pretty close to the intent of the state parameter in the OAuth 2 spec.
Regardless, the solution is up to our OAuth team. As such, when posting on JAC, please make sure to state the problem clearly and separate it from proposed solutions, which are still helpful but only imply the problem.
1 Like