-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assertion failure when access token reponse does not include refresh token #487
Comments
I found this info here: https://stackoverflow.com/a/54572538/3950982
I'm using the Android OAuth type in the developer console, so maybe this is why no refresh token is being sent? Either way, the code should not fail here with an assertion failure, if the refresh token isn't sent under some circumstances. |
It looks like you need to add |
Also quoted in that bug report:
Although another comment says consent has to be re-requested every 2 months or so. Is the refresh token being stored somewhere for the user, to avoid requesting it again? To get a new refresh token:
|
However adding |
See also this, re forcing the user to re-authorize, in order to obtain another refresh token. Is this done automatically by the googleapis library? https://stackoverflow.com/questions/8942340/get-refresh-token-google-api/10220362#10220362 |
@lukehutch – which version of |
I was using Currently this means it's pulling in version 1.3.1, since that is the latest version:
|
Weird!
https://github.com/google/googleapis.dart/blob/master/googleapis_auth/lib/src/auth_http_utils.dart#L98
That assert is not on line 98.
Could you send me a stack trace?
…On Tue, Jan 17, 2023 at 5:06 PM Luke Hutchison ***@***.***> wrote:
I was using serverpod_auth_server 0.9.21, which depends upon googleapis_auth
^1.3.0.
https://github.com/serverpod/serverpod/blob/main/modules/serverpod_auth/serverpod_auth_server/pubspec.yaml
Currently this means it's pulling in version 1.3.1, since that is the
latest version:
googleapis_auth:
dependency: transitive
description:
name: googleapis_auth
url: "https://pub.dartlang.org"
source: hosted
version: "1.3.1"
—
Reply to this email directly, view it on GitHub
<#487 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEFCR6MKM4VXDTL5ZNQPLWS46YBANCNFSM6AAAAAATUO44YQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
As discussed on Twitter, this bug was triggered by (a slightly modified version of) the serverpod_auth example code, but I don't have this code anymore, because I had to move on to use Firebase Authentication. It should be relatively easy to try running this example code to replicate the problem. https://docs.serverpod.dev/concepts/authentication |
@kevmoo I tried creating PR #524 to fix this bug, based on this suggestion but it didn't work -- what is the right way to force the user to consent to offline access? Here's what's going on:
final jsonMap = await client.oauthTokenRequest(
{
'client_id': clientId.identifier,
'client_secret': clientId.secret ?? '',
'code': code,
if (codeVerifier != null) 'code_verifier': codeVerifier,
'grant_type': 'authorization_code',
'redirect_uri': redirectUrl,
},
); The response of this request does not include a final refreshToken = jsonMap['refresh_token'] as String?; This is passed to return AccessCredentials(
accessToken,
refreshToken,
scopes,
idToken: idToken,
); These assert(credentials.refreshToken != null), Possible solutions:
|
I found a fix/workaround: by using the However, the |
In
oauth2_flows/auth_code.dart
, the functionobtainAccessCredentialsViaCodeExchange()
sends an OAuth2 token request, obtaining an access token as JSON, of the form:This is returned and stored in
credentials
inendpoints/google_endpoint.dart:230
. Then anAutoRefreshingClient
is instantiated using these credentials. That causes an assert failure inauth_http_utils.dart:98
:The access token JSON does not include
refresh_token
(which would be saved incredentials
asrefreshToken
byauth_code.dart:128
).This causes Google login to fail.
I don't know why the response does not include a refresh token in this case, but wouldn't it be better to still enable temporary login even if a refresh token is not provided by the server?
The text was updated successfully, but these errors were encountered: