Cypress automation when using the SPA SDK

Hi there,

Trying to keep it relatively high level, the blog post about automating the interaction with Auth0 from Cypress does not seem to work when using the SPA SDK.

It all goes well until handling the request back from the Cypress.env('auth_url'). Even when you configure the tenant correctly and get a 200 back with a valid token, etc the part where you fabricate a call back URL and force Cypress to follow it as indicated:

const callbackUrl = `/callback#access_token=${access_token}&scope=openid&id_token=${id_token}&expires_in=${expires_in}&token_type=Bearer&state=${auth0State.state}`;
cy.visit(callbackUrl, () => {
  // cookie setting, etc

…does not work. As I understand the SPA SDK has different expectations. There’s code flying around (Github) that suggests decoding the token and using local storage (but not everyone uses local storage). That sample code makes things even muddier by using cy.setLocalStorage() which is not part of the official Cypress API, it’s a plugin!

All in all, it would be a w e s o m e, if the blog post could be updated with official advice on how to handle Auth0 SPA SDK logins with Cypress.

Thanks a bunch!!!

Hi @jdelgado!

Welcome to the Community!

I don’t know if you saw my response on your tweet (from @Auth0Community), but I submitted a request for this to the team who handles the blog. I’ll add this thread to the request if there are any questions from them.


Hey @dan.woda is there an update to this? Even if not for a “fix” (documentation update), but at least when you think someone will take a look at it. So at least we can plan around it.



Hi @jdelgado, we are having some back and forth on it, should have an update shortly. Thanks for your patience! In the meantime, have you looked at the repo mentioned in this thread?

Thanks Dan.

Yeah, looked at both the repo and the code in that Github issue and neither worked for us. The implementation is very different too.

After getting a valid response from the auth URL one uses cookies, the other one localStorage. One decodes the token before saving it, the other forces a call to (presumably the callback URL?) with code and state like so: /?code=test-code&state=${stateId}.



Here is the update I got from our team who creates this content:

We are collaborating with Cypress on new guidance but we don’t have an ETA yet.

Thanks Dan.

I’m really happy that you are working with the Cypress team (truly!) but I don’t think this has to do with them. My feeling is that you’d have the same issue with any other driver / automation tool.

For me the issue is not having clear documentation about the SPA’s SDK expectations when coming back from the API call (cookie vs local storage, what to store in them, what URLs need to be called…).



If this is a documentation problem then I can suggest an update fairly quickly.

Can you elaborate on this? We have documented the storage options here. Are you saying its not clear where the tokens are stored?

No, I’m not saying that.

I’m saying it’s not clear a) what to store (regardless of cookies vs local storage) and b) what URLs to call and with which parameters, if any.

To be specific, neither the code in this Github comment nor this repo work or match what I see in my local environment.

The code in the Github repo comes closer but:

  • The key for the local storage proposed differs from the one I see being set by the SPA SDK in my app under test.
  • What the SPA SDK puts inside local storage has way more information than what the code in that Github comment proposes. If some of that extra information is optional, I don’t know.
  • Still not clear to me whether after setting the correct local storage object I can redirect anywhere in my app that requires credentials OR should I hit a specific local URL (and if so, with which parameters).



1 Like

Thanks for elaborating. Hopefully this info will be useful when they address the blog post.

As for right now, our team knows this is something that needs updated in our blogs/docs and are actively working on it.

Your best avenue is probably either the repo issue about it, or the other topic I linked where the user was able to get a solution. I’ll leave this thread open in case anyone has some input.

Ok, the plot thickens. Or maybe clarifies. But I need to provide more context.

I’m running this whole thing using Docker and Docker Compose. This is important because I don’t run my frontend app in localhost, but using its own service name as defined in the Docker Compose file (frontend).

I also run Cypress in a different container, so when I docker-compose up I need to tell Cypress that the application under test is running in http://frontend:3000. As you might have guess by now, this is no bueno, I’m getting a secure origin error as per this note in the documentation.

Because the origin frontend is not considered secure, the SPA SDK is throwing an error. This took a while to find out because running Cypress inside Docker is not particularly straightforward, so digging out relevant logs took a long time.

At this point I’m not sure how to proceed. Not sure if both Cypress and Auth0 are working as expected and I should find some other way to run the frontend application in a “secure” location (localhost) or if there’s anything I can do on my end to figure things out.