Closed mpgxvii closed 3 years ago
Hmm the intention of only sending the access token is that then the token is not refreshed in two places simultaneously, plus credentials are not needlessly delegated. Why not just request a new access token when it is needed for the Garmin backfill?
Hmm the intention of only sending the access token is that then the token is not refreshed in two places simultaneously, plus credentials are not needlessly delegated. Why not just request a new access token when it is needed for the Garmin backfill?
Access tokens in garmin are fixed. The user will need to de register and then authorise again to get a new access token. There is no other way to refresh the token.
We can maybe add a new endpoint to get the refresh token so that it is intentionally pulled by the external system?
Ok yes I can add a new endpoint
Hmm the intention of only sending the access token is that then the token is not refreshed in two places simultaneously, plus credentials are not needlessly delegated. Why not just request a new access token when it is needed for the Garmin backfill?
Access tokens in garmin are fixed. The user will need to de register and then authorise again to get a new access token. There is no other way to refresh the token.
Then why do we need the refresh_token with the access_token?. If user has to reauthorise, wouldn't it be better to use the PUT operation to update the access token in the back-end?
Alternatively, if you need to refresh the same access token, could the rest source authorizer return the same access token (since it is fixed) but refresh it when needed?
so GET token (Refresh if needed, return access token) POST token/refresh (Refresh, return access token)
Then why do we need the refresh_token with the access_token?. If user has to reauthorise, wouldn't it be better to use the PUT operation to update the access token in the back-end?
The user doesn't have to reauthorise. I was just saying that it is the only way to get a new access token. We don't need the new access token as the one will be valid.
Alternatively, if you need to refresh the same access token, could the rest source authorizer return the same access token (since it is fixed) but refresh it when needed? so GET token (Refresh if needed, return access token) POST token/refresh (Refresh, return access token)
We need the User Access token Secret (which is considered refresh token here) for signing the OAuth requests for backfill. Both the access token and access token secret are required. The secret is used in signing key https://github.com/RADAR-base/RADAR-PushEndpoint/blob/3e0125ed3844dbd89302a26b98a9520e036f5bbe/src/main/kotlin/org/radarbase/push/integration/common/auth/Oauth1Signing.kt#L61
Ah in that case, it might be better indeed to have a new endpoint that can sign a request:
POST token/sign
{url: “...?Param1=a¶m2=b”}
===
{
Url: ...
SignedUrl: ...
}
Yes, that sounds good to me. @mpgxvii can you make the suggested change (i think most of the signing code is already there) and I will update the code in push endpoint repo.
Ah in that case, it might be better indeed to have a new endpoint that can sign a request:
POST token/sign {url: “...?Param1=a¶m2=b”} === { Url: ... SignedUrl: ... }
Yes, that sounds good to me. @mpgxvii can you make the suggested change (i think most of the signing code is already there) and I will update the code in push endpoint repo.
Okay sure I can make the changes. Thanks
SignRequestParams
:{url: "", method: "", parameters: {}}