The Tempo API does not provide a self/me endpoint what is the desired way to fill in the “retrieveProfile” action within the oauth2 provider in a forge app to access the Tempo API?
Is there any user-related API that returns some name
and id
field for the consented user?
Unfortunately not, there is no API to retrive the Atlassian User with name/id field. The advise to use the https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-myself/ (“GET /rest/api/3/myself”) API from Jira.
But how can I use this within the oauth2 provider “retrieveProfile” request?
I see where the Tempo docs say to use the myself API you referenced: REST API Documentation (4.0)
Two things worth trying:
- Using the myself API for the
retrieveProfile
retrieveProfile:
remote: atlassian-myself
path: /rest/api/3/mypreferences
resolvers:
id: id
displayName: username
remotes:
- key: tempo-oauth
baseUrl: https://api.tempo.io/
- key: atlassian-myself
baseUrl: https://api.atlassian.net/
I’d be super surprised if this worked because it would mean that the Tempo token can be used against the Jira API. But this snippet from the Tempo docs kind of makes it sound like that is the case:
Identifying users
The Tempo REST API uses the Atlassian accountId to identify users. The accountId is an opaque identifier that uniquely identifies the user.
The accountId of the current user can found using the Jira Myself API.
Information about a user, given the accountId, can be retrieved using the Jira User API.
- Use the response from a GET to Tempo’s
/accounts
. You get back anid
and aname
from the accounts endpoint:
"id": 7,
"name": "Cloudbay: Development",
I wonder if you can use those to hydrate the user profile feeds. Note: I don’t have a great understanding of how the profile data is used throughout the Forge app so it might be a very bad practice to use names/ids that could be “assigned” to multiple users of your app. I’ll see if @MichaelCooper can provide some more thoughts on this.
Thanks for the advices.
-
This is what I have already tried 2 weeks ago, but without success. Anyway I will try again, but I think that the JIRA API does not accept the Tempo token (which you already mentioned)
-
Tempo’s /accounts API is totally different from a Jira/Atlassian User, these accounts are somewhat else for managing time tracking to e.g. a customer account.
The profile retriever is currently used for 2 things:
- To allow the user to differentiate between multiple accounts on the Connected Apps screen.
- To differentiate between a new account and an existing account.
When finishing the OAuth flow, if the id
field from the profile retriever is the same as previously (for this user), it will replace the existing token.
However, if it’s different, it will add a second token.
It would be fine if it was always the same value, you just would never be able to link multiple accounts.
However, if it was different every time, the user would end up with lots of tokens, and result in some weird behaviour.
I hope this helps
What I was predicting: when using the /read/api/3/mypreferences
then I will get a 401:
could not retrieve profile information: {"message":"Client must be authenticated to access this resource.","status-code":401}
Ok I tried again my workaround which works 2 weeks before but was broken after a Forge update:
I write my own profile retriever with an API to Tempo which works without any problems, but then it was broken until the recent Forge update from yesterday
I used this in my manifest:
function:
- key: main
handler: index.run
providers:
auth:
- tempotime
- key: tempo-profile
handler: auth.retriever
...
retrieveProfile:
remote: tempo-apis
path: /core/3/work-attributes/
function: tempo-profile
...
remotes:
- key: tempo-apis
baseUrl: https://api.tempo.io
And in my auth.ts file in the retriver function I return a static object:
...
return new AuthProfile({
id: '12345',
displayName: 'Some Name',
});
...
@bentley and @MichaelCooper thanks for your help.