Closed justmobilize closed 11 months ago
As a follow up, I am happy to open this PR
I am also facing this issue right now with another use case.
Thanks for reaching out.
What version of the SDK are u using?
With v2, you can do the following:
<Auth0Provider
domain={identityProvider.domain}
clientId={identityProvider.clientId}
authorizationParams={{
redirect_uri: window.location.origin,
foo: 'bar"
}}
>
</Auth0Provider>
Doing the above ensures foo
is set with a value of bar
on all requests to /authorize
as well as the calls to oauth/token
when grant_type is set to refresh_token
, including when checkSession
is calling getTokenSilently
, but also when you call getTokenSilently
without setting foo
explicitly on that method call.
Would that help?
@frederikprijck - Thank you.
We are currently on v1.9 - we implemented a while ago. This sounds promising.
Is there a way to update the authorizationParams
after the <Auth0Provider />
is created? The value we send up will be different based on the logged in user, so need to be able to change it once there is a logout/login.
Not sure i understand what you mean. The question was about checkSession, which typically only hits auth0 before knowing if the user is logged in.
Once that's over, you can pass anything to getTokenSilently and it will override whatever is set in the auth0provider.
With V1, you can try putting the custom param (foo in the example above) on the same level as domain and client id, we moved custom parameters to it's own "authorizationParams" in V2, but the functionaly existed in V1 by putting them on the root of the object.
Regardless, i do recommend updating to V2.
So the issue is that on a hard refresh of the page (or opening in a new tab) after the JWT Token
has expired but the user is still logged in, the call to checkSession
is made.
I would prefer to clear out the value set on the init, vs a bug creeping up because somewhere we didn't override the value in a call to getTokenSilently
.
And yes, will 100% update to the newest version.
You can not update the authorizationParams no.
What you can do, is wrap our call to getTokenSilently to make it so it always uses the correct params based on the logged in user.
Do you happen to have an example of how to wrap that call? Because that would make everything way easier (aka not needing to worry if someone adds a call using that and forgets to pass the params).
What I mean is roll your own hook, or whatever solution you see fit.
Not tested, but pseudo wise something:
const { getAccessTokenSilently } = useCustomAuth0();
Where useCustomAuth0
would look something like this:
function useCustomAuth0() {
const auth0 = useAuth0();
const myState = useMyState();
return {
...auth0,
getAccessTokenSilently: () => auth0.getAccessTokenSilently({ authorizationParams: { foo: myState.foo } })
}
}
That should allow you to ensure the correct parameters are always passed to our SDK.
Checklist
Describe the problem you'd like to have solved
I am creating some custom Flows in which I need information from the client application. When I call
getTokenSilently
, I can pass in custom keys. But whenAuth0Provider
is initiated, it callscheckSession
that callsgetTokenSilently
which I can't control.Describe the ideal solution
That
Auth0ProviderOptions
would contain an option to setGetTokenSilentlyOptions
to pass togetSession
Alternatives and current workarounds
I haven't found any alternatives yet.
Additional context
No response