Provide alternative for e2e

[markusahrweileramcon]

Core Library

MSAL.js (@azure/msal-browser)

Wrapper Library

MSAL Angular (@azure/msal-angular)

Public or Confidential Client?

Confidential, Public

Description

In msal-angular 3.0.16 I could fake a valid login by putting a custom json into the localStorage.
With 4.0.20, encryption was added, So I no longer have the option to run my tests.

Checking the documentation, I was shocked. In my opinion, you cannot expect people to create a test user and store those credentials in code.
Relying on a fully functional productive login would also require a connection to the microsoft services.
What if the connection is unstable and my Tests are flaky/flipping?

Also having the need for a test user would create cost for a license, no?
Since the user needs to be able to login and have permissions. Which would also be a security issue, if all the company members could login with the test user and change data "anonymous".

There should be a better way to create a valid login for e2e. Since we mock all requests to our API, we will never have any problems with a user which does not actually exist. Permission checks are always executed on the server, so even if that code would leak into propduction and users could fake their login, they cannot pass the api

[tnorling]

loadExternalTokens is the supported and recommended way to hydrate the cache with tokens for testing purposes. Please do not read/write from the cache directly as the keys/values are not part of our public API surface and are subject to change at any time. The loadExternalTokens API does not have any requirement that the tokens be "real", you're free to provide dummy tokens if you like.

[markusahrweileramcon]

Yeah, I came across the "subject to change at any time" :D
I could not find this recommendation in microsofts documentation (https://learn.microsoft.com/en-us/entra/msal/dotnet/advanced/testing-apps-using-msal)

I would love, if we could find a hint there.
I checked the markdown file quickly and at first, I had the question, how I would update the client in my application but the e2e example made me realize, that I only need the PublicClientApplication to store the tokens in my storage.

Do you think it might be worth to update the documentation to hint, that you don't need to replace your productive code with that instance? 🤔

Anyway thank you for clarifying

[markusahrweileramcon]

BrowserAuthError: non_browser_environment: Login and token requests are not supported in non-browser environments.

So if I get the Playwright Testing Example right, you still expect me to create an account in azure and I don't have the option to provide any valid authentication in playwright

[tnorling]

BrowserAuthError: non_browser_environment: Login and token requests are not supported in non-browser environments.

This needs to be run in the browser process, not the node process that is executing the tests.

So if I get the Playwright Testing Example right, you still expect me to create an account in azure and I don't have the option to provide any valid authentication in playwright

This is just an example that shows the most common use case. A real account is not required.

[markusahrweileramcon]

Even after another several hours of trial and error, I come to the assumption, that it does not work:

const serverResponse = {
    token_type: AuthenticationScheme.BEARER, // "Bearer"
    scope:scope,
    expires_in: 3599,
    access_token: 'access-token-here',
}
if (sessionStorage['msal.1.account.keys'] == null) {
    pca.getTokenCache().loadExternalTokens(
        silentRequest,
        serverResponse,
        loadTokenOptions).then(() => {
        location.reload()
    }, error => {
        console.error(error)
    })
}

@azure/msal-browser@4.25.1 : Info - handleRedirectPromise called but there is no interaction in progress, returning null.

If the content in access_token is important, than I would like to know how I would know, what to provide.
This documentation is a joke. You say, that I dont need a real account, but you dont provide ANY information how to provide a valid token which is safe enough to store it in a repository.

[tnorling]

You might find our integration tests helpful as they do not make any network calls and rely only on hardcoded dummy tokens. The access token value is unimportant, we don't crack it open, what you have here is fine (and in fact you'll see we provide a similar value in our own tests). You do, however, need to ensure that there is either an idToken (jwt format, but can be self issued/hardcoded) in the serverResponse OR an account in the silentRequest. The logs outputted by loadExternalTokens should indicate to you whether it was successful or if it was missing necessary information.

@azure/msal-browser@4.25.1 : Info - handleRedirectPromise called but there is no interaction in progress, returning null.

This is not an indication that the API didn't work. This will be logged every time handleRedirectPromise is called unless there is an active redirect request in progress (e.g. you called acquireTokenRedirect first). Instead you should call acquireTokenSilent with the same silentRequest object you passed into loadExternalTokens. It should return the accessToken you provided.