Open dragomir-parvanov-riskmethods opened 1 year ago
Hi @dragomir-parvanov-riskmethods , thank you very much for your issue and sorry for the delay. I am not sure to understand your need. What is your react-oidc configuration? Where come from you access_token?
I need more technical detail to understand your flow. I know this kind of senario are using the extras parameters to change of user.
For retrieving specific session we generally do not share any tokens. For exemple if we include a widget inside a wesite. We use silent login or of full login to retrieve tokens inside the widget included in a website. This is better for security reason and in general tokens does not require same scopes and domains.
Hi, thanks for the response The thing we want to achieve we call it "impersonation" What we want to achieve is skipping the login step with an access_token token that we retrieve from our back-end. After _setting the token to react-oicd that we receive from our back-end server(it is the same one as the one received by react-oicd after the user enter his credentials) s, we expect react-oicd to keep the same flow - hooks usage, refreshing of that token and redirecting to the login page if the token had expired. Here is our config:
{
client_id: clientId,
redirect_uri: `${window.location.origin}/auth/our-site/callback`,
scope: 'public',
authority: baseUrl,
authority_configuration: {
issuer: baseUrl,
authorization_endpoint: `${baseUrl}/authorize`,
token_endpoint: `${baseUrl}/token`,
revocation_endpoint: 'http://dummy', // this entry is required by type, hence a dummy value
},
}
we managet to create PoC on "@axa-fr/react-oidc-context": "^3.1.7" with setting sessionStorage before "@axa-fr/react-oidc-context" loads, but it is kinda messing with the internals and in version 6.x, the sessionStorage is different
Hi @dragomir-parvanov-riskmethods , very sorry for the delay. Do you have a video or somethi g that can help me to understand your need?
Hello, just to chime in now that I'm responsible for updating this package to the newest version, or at least getting it to build with a newer TypeScript version (5.3.3). We're using the following functions directly, and not having them exported from the index file causes TypeScript to attempt to type check them, causing our build to fail:
import { initSession } from '@axa-fr/oidc-client/src/initSession';
import { setTokens as setOidcTokens } from '@axa-fr/oidc-client/src/parseTokens';
We use NX and Next.js in our project, attempting to build it (not type check or run a development server), causes the following error:
../../node_modules/@axa-fr/oidc-client/src/initSession.ts:1:29
Type error: Parameter 'configurationName' implicitly has an 'any' type.
> 1 | export const initSession = (configurationName, storage = sessionStorage) => {
| ^
2 | const clearAsync = (status) => {
3 | storage[`oidc.${configurationName}`] = JSON.stringify({ tokens: null, status });
4 | return Promise.resolve();
Error occurred while trying to run the build command
Trying to ignore implicit any
checks just causes another error inside of the same function to pop up.
Previously, we were piggy backing off the bundled version of oidc-client
bundled inside of react-oidc
:
import { initSession } from '@axa-fr/react-oidc/dist/vanilla/initSession';
import { setTokens as setOidcTokens } from '@axa-fr/react-oidc/dist/vanilla/parseTokens';
I think the easiest way to resolve our errors would be to expose at least the functions we use from the library in the index
file, which is very selective as to what it exposes at the moment.
The whole issue is somewhat urgent, as we're trying to catch up on major dependency updates and resolve a security vulnerability.
Hi @UwUnyaa ,
Do you have a sample of your configuration ? Are you using service worker?
For which use case use the method?
You already have tokens for somewhere else?
Do you have a sample of your configuration?
Since we don't use a service worker, there's no configuration file to speak of. Authentication and impersonation are handled by a separate domain and application.
Are you using service worker?
We're not using it.
For which use case use the method?
We're using initSession()
and manually pass to it tokens (using setTokens()
) we get from the URL search parameters to handle impersonation (letting an admin user log in as a particular use for support and/or debugging purposes). This is because the user is picked from another application that just passes a link.
You already have tokens for somewhere else?
There's only one file in our whole monorepo (which doesn't contain every single project in the application as it's a language-centric repo) where we use both initSession()
and setTokens()
.
Hello! Would anyone please share how we can achieve the following scenario:
We do have the access token for the user that we need to "impersonate," but we cannot set it as an initial access token value to react-oicd.