oidc-client-ts icon indicating copy to clipboard operation
oidc-client-ts copied to clipboard

Cannot catch events

Open paillave opened this issue 2 years ago • 8 comments

On my front end application, I try to observe what is happening regarding authentication. So I use the following code in a root component that is the direct child of AuthProvider

    const auth = useAuth();
    React.useEffect(() => auth.events.addUserSignedIn(() => console.log("-->addUserSignedIn")), [auth.events]);
    React.useEffect(() => auth.events.addAccessTokenExpiring(() => console.log("-->addAccessTokenExpiring")), [auth.events]);
    React.useEffect(() => auth.events.addAccessTokenExpired(() => console.log("-->addAccessTokenExpired")), [auth.events]);
    React.useEffect(() => auth.events.addUserLoaded(() => console.log("-->addUserLoaded")), [auth.events]);
    React.useEffect(() => auth.events.addUserUnloaded(() => console.log("-->addUserUnloaded")), [auth.events]);
    React.useEffect(() => auth.events.addSilentRenewError(() => console.log("-->addSilentRenewError")), [auth.events]);
    React.useEffect(() => auth.events.addUserSignedOut(() => console.log("-->addUserSignedOut")), [auth.events]);
    React.useEffect(() => auth.events.addUserSessionChanged(() => console.log("-->addUserSessionChanged")), [auth.events]);

The only event that is raised is addUserLoaded. No other event is raised, whereas auth content is complete and accurate. When looking into https://github.com/authts/oidc-client-ts/blob/main/src/SessionMonitor.ts, it looks like it is intentional.

Is there a way for me to catch these events?

paillave avatar May 25 '22 11:05 paillave

  • addUserSignedIn, addUserSignedOut and addUserSessionChanged only work in combination with SessionMonitor
  • addAccessTokenExpiring and addAccessTokenExpired are fired when the access token has nearly expired, that may take serveral hours until it happen
  • addSilentRenewError needs renew feature enabled and it needs to fail, there is a retry until timeout loop
  • addUserUnloaded is triggered when you explicitly unload the user e.g. with mgr.removeUser()

If you have doubts you can enable logging to the console of this library. See https://authts.github.io/oidc-client-ts/#logging

pamapa avatar May 25 '22 13:05 pamapa

Actually, I wanted to rely on these events to dispatch redux actions in my application. So I want to listen everything to change my state accordingly. What do you mean with "only work in combination with SessionMonitor"? When can I find an example?

paillave avatar May 25 '22 14:05 paillave

What do you mean with "only work in combination with SessionMonitor"? When can I find an example

Those event are only raised in the SessionMonitor, as such that monitor needs to be active (settings.monitorSession).

pamapa avatar May 25 '22 15:05 pamapa

Is this what you want to achieve? https://github.com/authts/react-oidc-context/blob/main/src/AuthProvider.tsx#L169

pamapa avatar May 25 '22 15:05 pamapa

Is this what you want to achieve? https://github.com/authts/react-oidc-context/blob/main/src/AuthProvider.tsx#L169

As a matter of a fact, I am already using react-oidc-context. What I see inside is actually the same subscription to events than what I'm doing (I switched settings.monitorSession to true, made this Log.setLevel(Log.DEBUG); and this Log.setLogger(console);).

I still can't find out a clear way to reach these events. Moreover I would say, if we can subscribe to these events, it looks like they should be raised anyway.

paillave avatar May 30 '22 08:05 paillave

Are you using ReactStrict mode with react-oidc-context?

pamapa avatar Jun 02 '22 09:06 pamapa

Are you using ReactStrict mode with react-oidc-context?

Yes I am.

Actually, I would like to give my own instance of UserManager, but AuthProvider component doesn't accept an instance of UserManager but the type.

Not only that I don't really see the point of this given the fact that both implementation and userManagerSettings are used only in the following lines of code.

https://github.com/authts/react-oidc-context/blob/a924f4d555d4db265a5a350f63d348a176e3b346/src/AuthProvider.tsx#L111-L118

In this situation, it would be way more convenient for the developer to give an instance so that he can have a way interact with what is going on with the authentication process.

(yes I realise that, at the end of the day, this ticket should be on the project https://github.com/authts/react-oidc-context that is yours as well 😃 )

PS: I understand that the reason why you want to get a type and not an instance is because you want to have control on the life cycle of the object for developer not to float you with "bugs" due to the fact they recreate a new instance of this manager everytime.

paillave avatar Jun 02 '22 10:06 paillave

Are you affected by https://github.com/authts/react-oidc-context/issues/390. I assume we need to add something for this mode to work properly. Does it work without that mode?

pamapa avatar Jun 02 '22 11:06 pamapa