attempt to getTokens after call to logout results in exception

[justin-barca-at-camis]

In Chrome, the following exception is unhandled when getTokens is called after logout:

Uncaught (in promise) DOMException: Failed to execute 'postMessage' on 'ServiceWorker': Port at index 0 is already neutered.
    at Object.<anonymous> (https://localhost:3000/static/js/vendors~main.chunk.js:67061:28)
(anonymous) @ appAuthHelper.js:272
Promise.then (async)
(anonymous) @ appAuthHelper.js:266
Promise.then (async)
(anonymous) @ appAuthHelper.js:264
(anonymous) @ appAuthHelper.js:281
registerIdentityProxy @ appAuthHelper.js:259
(anonymous) @ appAuthHelper.js:114
postMessage (async)
(anonymous) @ appAuthHelperFetchTokensBundle.js:46
Promise.then (async)
(anonymous) @ appAuthHelperFetchTokensBundle.js:46
2../TokenManager @ appAuthHelperFetchTokensBundle.js:46
t @ appAuthHelperFetchTokensBundle.js:46
(anonymous) @ appAuthHelperFetchTokensBundle.js:46
3../appAuthHelperFetchTokens @ appAuthHelperFetchTokensBundle.js:46
t @ appAuthHelperFetchTokensBundle.js:46
s @ appAuthHelperFetchTokensBundle.js:46
(anonymous) @ appAuthHelperFetchTokensBundle.js:46

However, with Firefox one gets React error boundary catching the error, resulting in the more cryptic, maybe it tried to serialize

Unhandled Rejection (DataCloneError): The object could not be cloned.

I used the following component in React in order to test the workflow.

import React, { useEffect, useState } from 'react';
// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore
import AppAuthHelper from  'appauthhelper';
import { Toolbar } from '@mui/material';

// Make the authorization request

export const AuthTest = () => {
    const [data, setData] = useState<any>(null);
    useEffect(() => {
        AppAuthHelper.init({
            clientId: 'warden.mobile',
            scopes: 'openid profile',
            'authorizationEndpoint': 'https://localhost:44320/provider/auth',
            'tokenEndpoint': 'https://localhost:44320/provider/token',
            'revocationEndpoint': 'https://localhost:44320/provider/token/revocation',

            tokensAvailableHandler: function (claims: any, id_token: any, interactively_logged_in: any) {
                const data = { claims, id_token, interactively_logged_in };
                // eslint-disable-next-line no-console
                console.log('>>>>>>>>>>>>>>>>>>>>>>>>>', data);
                setData(data);
            },
            renewCooldownPeriod: 1,
            oidc: true,
            identityProxyPreference: 'serviceWorker', // Can be either "XHR" or "serviceWorker"
            renewStrategy: 'authCode', // Can be either "authCode" or "refreshToken"
            redirectUri: 'appAuthHelperRedirect.html', // Can be a relative or absolute url
            serviceWorkerUri: 'appAuthServiceWorker.js' // Can be a relative or absolute url
        }).then(() => {
            AppAuthHelper.getTokens();
        });
    }, []);
    return (
        <div>
            <button onClick={() => {
                AppAuthHelper.getTokens();
            }}>Login</button>
            { JSON.stringify(data, null, 2)}
            <button onClick={() => {
                setData(null);
                AppAuthHelper.logout();
            }}>Logout</button>
        </div>
    );
};

In order to reproduce this error, these steps are taken:

1. Click "Logout" after token string appears
2. Click "Login" after logout request completes

[jakefeasel]

Based on my reading of the code, this would only be possible if calling AppAuthHelper.logout(); doesn't actually end your session at the OP. Because of this, the call to AppAuthHelper.getTokens(); would be successful without a full-page redirection (i.e. it would be able to get fresh tokens using a silent auth code grant). Once that grant returns, the current code attempts to establish the IdentityProxy, which in this case isn't necessary because it was already established earlier. So, the fix for this case will be to just check to see if the IdentityProxy has already been established and skip it it is has.

It is somewhat of a strange behavior that your OP preserves the session after you call logout, though, isn't it?

[jakefeasel]

@justin-barca-at-camis could you try the PR I added for this and see if it resolves it for you: #40