I’m trying to implement oauth2 for this service Authenticating with TeamGantt | TeamGantt Support (post shows all necessary endpoints and payloads)
This is my manifest:
providers:
auth:
- key: teamgantt
name: TeamGantt
type: oauth2
scopes:
- email
- openid
- profile
clientId: <redacted>
bearerMethod:
type: authorization-header
prefix: "Bearer "
parameter: Authorization
remotes:
- teamgantt-api
actions:
authorization:
remote: teamgantt-auth
path: /login
exchange:
remote: teamgantt-auth
path: /oauth2/token
resolvers:
accessTokenExpires: expires_in
revokeToken:
remote: teamgantt-auth
path: /revoke
retrieveProfile:
remote: teamgantt-api
path: /v1/current_user
resolvers:
id: id
displayName: email_address
The issue is that after I do login, it stays logged in for a while, and then it randomly logs me out during triggers for example, when running code like:
const response = await api
.asUser()
.requestJira(route `/rest/api/3/project/${projectIdOrKey}`);
return response.json();
Which returns
[NEEDS_AUTHENTICATION_ERR: Authentication required] {
serviceKey: 'atlassian-token-service-key'
}
My login code looks like so:
resolver.define('credentials', async ({context}) => {
const teamgantt = api.asUser().withProvider('teamgantt', 'teamgantt-auth');
const hasCredentials = await teamgantt.hasCredentials();
if (!hasCredentials) {
await teamgantt.requestCredentials();
}
return await teamgantt.hasCredentials();
});
1 Like
It feels like some of the issue is using two remotes? teamgantt-auth and teamgantt-api (both on *.teamgantt.com). How does the token used when authenticating with teamgantt-auth get shared with teamgantt-api?
I changed the jira rest request to use asApp()
and that kind of fixed the issue, but later when I use teamgantt.fetch(....)
I get something like:
ERROR 15:03:23.283 2d15b33dddaf66fe Fetch failed for remote 'teamgantt-api', provider 'teamgantt', path '/v1/projects/<id>/children?is_flat_list=true' no credentials previously requested
I tried using ‘teamgantt-api’ as the remote when requesting credentials and no luck there. I commented out the if (!hasCredentials) {
guard to get it to reauth when changing those (no obvious logout methods I can find).
From an initial look here, it looks like either your initial grant flow isn’t working, or the refresh flow.
Your configuration provider definition looks correct.
api.asUser().withProvider('teamgantt', 'teamgantt-auth')
On the provider definition, the second argument (in this example teamgantt-auth
) being the remote to use for your requests, so this should also match the urls you are calling.
There seems to be something missing from what you have described, so it’s hard to know why this isn’t working for you. How are you calling credentials
resolver?
Can you provide some more details?
1 Like
We’re using the credentials
resolver via the UI bridge.
The teamgantt-auth
is defined in the top level remotes config:
remotes:
- key: teamgantt-auth
baseUrl: https://auth.teamgantt.com
Sorry for the run around here, but the “error” you showed here in the forge tunnel
log says:
serviceKey: 'atlassian-token-service-key'
Which means its not the teamgantt
service that needs authentication again, but the atlassian app consent grant.
When you say “it randomly logs me out”, what consent flow is it sending you down, the atlassian one or the teamgantt one?
If its the atlassian one, it may be related to an issue we are already tracking internally.
If its the atlassian one, it may be related to an issue we are already tracking internally.
Very possible. It might be both, because we did see other errors related to auth but those didn’t seem to be atlassian based. Could the atlassian service affect the oauth providers?
Yes, the atlassian auth token is required before any other external auth tokens are processed.
So first it’s necessary to auth asApp
followed by asUser
?
No, that is not necessary. Whenever you use asUser
we use the existing consent. It’s not necessary to do that before using your provider.
1 Like
Hi @IlyaRadchenko , can you please check again if the issue persists?
We have recently fixed an issue causing consent loops.
We are keen to see if that has solved your issue, or if its still happening.