feat: token behavior improvements

[Eisie96]

PR Type

[ ] Bugfix
[ x ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] CI-related changes
[ ] Documentation content changes
[ ] Application / infrastructure changes
[ ] Other:

What Is the Current Behavior?

The new token api is introduced with the PWA version 3.2 (#1156). Since then, we are dealing with some issues, which needed to be addressed.

• The ICM token functionality is split into multiple files. The configuration of the OAuth service (identity-provider) is executed in a different place then fetching the token (user.service.ts). This can lead to a runtime issue, when the oAuthService wants to fetch a new token, although the whole service is not yet configured.
• The PWA can now be initialized with two different oAuthService combination. (Auth0 and default ICM token behavior). Right now all configurations are sharing just one oAuthService instance. This can lead to unneccary side effects (overriden configuration)
• The anonymous user token is fetched everytime no apiToken is available. This is not necessary. The token is only needed, when a new basket should be created.

Issue Number: Closes #1374

What Is the New Behavior?

The OauthConfigurationService is replaced by the TokenService. The service will inject it's own OAuthService instance and is responsible for it's configuration and fetching token mechanism. All identity provider are not relying on the internal ICM token behavior anymore.

The anonymous user token behavior is adapted. It will only be fetched, when an anoymous user will create a basket. The functionality is included in the ApiTokenService intercept method.

Does this PR Introduce a Breaking Change?

The identity provider needs to be adapted. These providers are not responsible anymore to configure the oAuthService for fetching ICM tokens.

When a identity provider needs a OAuthService (e.g. auth0-identity-provider), then it has to inject the dependency with a complete new OAuthService instance. Otherwise it could lead to unnecassary side effects. (e.g. during configuration)

  @Injectable({ providedIn: 'root' })
  export class Auth0IdentityProvider implements IdentityProvider {
    private oauthService: OAuthService;
  
    constructor(
      parent: Injector,
    ) {
      const injector = Injector.create({
        providers: [{ provide: OAuthService }],
        parent,
      });
  
      this.oauthService = injector.get(OAuthService);
    }
}

[ x ] Yes
[ ] No

Other Information

AB#85534

[Eisie96]

@tbouliere-datasolution

Hello Tristan, could you have a look on this PR? We have improved the token handling in the PWA and need some further feedback from you. :)

[tbouliere-datasolution]

Hi @Eisie96
I haven't tested it thoroughly, but doesn't the following function

intershop-pwa/src/app/core/services/token/token.service.ts

Lines 92 to 101 in 11fd815

	private setApiTokenCookie$() {
	return this.oAuthService.events.pipe(
	filter(event => event instanceof OAuthSuccessEvent && event.type === 'token_received'),
	map(() =>
	this.apiTokenService.setApiToken(this.oAuthService.getAccessToken(), {
	expires: new Date(this.oAuthService.getAccessTokenExpiration()),
	})
	)
	);
	}

force an anonymous token ?

Won't this invalidate the sso token when this function is called?

[Eisie96]

Hi @Eisie96 I haven't tested it thoroughly, but doesn't the following function

intershop-pwa/src/app/core/services/token/token.service.ts

Lines 92 to 101 in 11fd815

	private setApiTokenCookie$() {
	return this.oAuthService.events.pipe(
	filter(event => event instanceof OAuthSuccessEvent && event.type === 'token_received'),
	map(() =>
	this.apiTokenService.setApiToken(this.oAuthService.getAccessToken(), {
	expires: new Date(this.oAuthService.getAccessTokenExpiration()),
	})
	)
	);
	}

force an anonymous token ?
Won't this invalidate the sso token when this function is called?

Thank you for your response!

The linked function will not fetch an anonymous user token. It will only set the apiToken within the api-token.service.ts to use them for all ICM request. The anonymous user token will only be called, when no apiToken is available (here not the case) and the basket request will be fetched.

[shauke]

Problem with anonymous apiToken cookie from ICM in Hybrid Approach

When switching back from an ICM rendered page in Hybrid Approach where an anonymous apiToken cookie was set without a basket, the PWA tries to fetch the basket for that cookie and fails (REST error).
This results an disabled "Add to Cart" buttons in the whole PWA.

Other than this the rework looks good and worked with SSO and Punchout tests as expected.

[shauke]

Fixed Hybrid Approach issue that was independent from the token behavior improvements. Had the same problems before.