Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login through Azure AD account. #1342

Open
alborozd opened this issue Feb 19, 2018 · 97 comments
Open

Login through Azure AD account. #1342

alborozd opened this issue Feb 19, 2018 · 97 comments

Comments

@alborozd
Copy link

@alborozd alborozd commented Feb 19, 2018

Current behavior:

I use Azure AD to authenticate my users.

My logic:

When user opens the browser and get 401 status code from my api then application redirects to https://login.microsoftonline.com/.... page to input login and password and then microsoft redirects back with access token for my application.

Now when I open my page cy.visit("http://localhost:8080") I just get 401 status code from my application and it doesn't redirect me to input login and password.

I tried to open login page directly to check login and password typing: cy.visit("https://login.microsoftonline.com");

but cypress can't load this page and fails with timeout.

In dev tools I see that it tries to load page content all the time.

My cypress,json file:

{
	"chromeWebSecurity": false
}

Selenium works fine with this case.

Desired behavior:

Cypress can redirect me to https://login.microsoftonline.com to input login and password and redirect back to http://localhost:8080.

https://login.microsoftonline.com should be open correctly.

How to reproduce:

  1. cy.visit("https://login.microsoftonline.com");
  2. Try to get 401 status code from your application and redirect to https://login.microsoftonline.com

Test code:

describe("Integration tests", function() {
	it("login", function() {
              cy.visit("http://localhost:8080");
              //cy.visit("https://login.microsoftonline.com");
	});
});

Additional Info (images, stack traces, etc)

CypressError: Timed out after waiting '60000ms' for your remote page to load.
Your page did not fire its 'load' event within '60000ms'.
You can try increasing the 'pageLoadTimeout' value in 'cypress.json' to wait longer.
Browsers will not fire the 'load' event until all stylesheets and scripts are done downloading.
When this 'load' event occurs, Cypress will continue running commands.
  • Operating System:
    Windows 10 pro
  • Cypress Version:
    2.0.2
  • Browser Version:
    Chrome 63
@brian-mann
Copy link
Member

@brian-mann brian-mann commented Feb 19, 2018

You're trying to test SSO - and we have recipes showing you exactly how to do this.

Also best practice is never to visit or test 3rd party sites not under your control. You don't control microsoftonline, so there's no reason to use the UI to test this. You can programmatically test the integration between it and your app with cy.request - which is far faster, more reliable, and still gives you 100% confidence.

Look at this recipe - it employs the exact principles you can use to test the integration between the two.

Click the giant "Single Sign On" link and you'll be taken the recipes code.

@pieterdv
Copy link

@pieterdv pieterdv commented Feb 27, 2018

Hey @brian-mann, I looked at the recipes, but unless i'm mistaken, Microsoft is not allowing Resource Owner Password Credentials grant for web applications. So testing with cy.request and sending the username / password seems not to work. Do you have alternative ideas? Also looking forward to extra documentation for this!

@blex18
Copy link

@blex18 blex18 commented Apr 24, 2018

@brian-mann I totally agree with the best practices and the reasons behind them make perfect sense. The problem is microsoftonline is not only SSO - it is an ActiveDirectory. The tokens issued on login are then being used to access other resources like MS Graph API from within the application. Is there any recipe to test a web application that so massively rely on 3rd-party API that there is no single page that doesn't make at least 1 request to external resources?

@pieterdv
Copy link

@pieterdv pieterdv commented Apr 24, 2018

@blex18 as a work around for now I use puppeteer to do the login in microsoftonline, then I set the variables that are in puppeteer localstorage in cypress localstorage and from there on i can continue. Not an ideal workflow but it works

@brian-mann
Copy link
Member

@brian-mann brian-mann commented Apr 24, 2018

@pieterdv and @blex18 you can just use cy.request().

@pieterdv I have no idea what your comment meant in regards to microsoft not allowing ROPC grant for web applications. A cy.request acts as if it comes from the browser but is not bound to any CORS restrictions. There is no difference between making a cy.request and using the browser - zero. As long as you provide to cy.request what the browser would have sent it will work the same and avoid using the UI.

I can say with 100% guarantee it will work, but you just have to figure out what microsoft is accepting. Try reading their docs to see what API's they expose to programmatically log in. Or instead - capture all of the network traffic at the browser level and inspect it to see what the browser sent.

@brian-mann
Copy link
Member

@brian-mann brian-mann commented Apr 24, 2018

@blex18 as for recipes - yes, we specifically show a SSO example in our recipes that interact with a 3rd party server. There is no difference between that example and any other 3rd party services - whether its oauth, sso, saml, etc. It's all the same, and you interact with them with cy.request which is nothing more than a programatic http request, the same ones that come from your browser.

@pieterdv
Copy link

@pieterdv pieterdv commented Apr 24, 2018

@brian-mann I'm using the msal library provided by microsoft to do the authentication in the app. The request from the library is just a redirect with an identifier to the azure ad login page. That is possible to simulate with cy.request, but that won't help, because you only get a page where you have to enter your credentials, and sending a request with your credentials in body is not allowed by microsoft as i stated before. This is mainly a restriction by Microsoft and not something Cypress can do much about at this moment in my opinion.

@blex18
Copy link

@blex18 blex18 commented Apr 24, 2018

@brian-mann, thanks for the prompt response. Believe me, I went through the docs linked in the original response. The problem with the SSO recipe is it assumes the login form is an html form.

In case of login.microsoftonline.com it is a webpacked knokoutjs app which does much more than just rendering a login form. Form submission requires not only login and password, but a bunch of other fields populated by microsoft runtime. In fact there are 2 consecutive forms - first login, then password. So basically I am stuck with this "providing to cy.request what the browser would have sent".

I did capture the traffic from the browser. Reverse engineering would be quite expensive and extremely brittle exactly because of the The 3rd party site may have changed or updated its content reason, so I was wondering if there is any example of how to capture dynamic parameters to actually build cy.request.

Azure provides quite rich API to log in programmatically, and even maintain multiple versions of it. The problem is they distinguish programmatic logins from interactive ones, but I believe @pieterdv already mentioned it. I am using these API, and there is no need for a browser to test this scenarios. Plain request is more than enough. It does not cover cases with interactive user login though, and that's exactly where I hoped your reliable testing of anything that runs in a browser could help.

@beanian
Copy link

@beanian beanian commented May 22, 2018

@pieterdv do you have any sample code you can share on how to use puppeteer to login to AAD and subsequently set these cookies in cypress?

@blex18
Copy link

@blex18 blex18 commented May 22, 2018

@beanian setCookie is pretty well documented, and it's not the best place to ask puppeteer questions. I am sure you will have better chances on Q&A sites like stackoverflow.

@saschwarz
Copy link

@saschwarz saschwarz commented May 22, 2018

@blex18 I think the question is relevant to the OP's question. When using AD for authentication, they use a multi-step login wizard and there don't appear to be any endpoints to which you can POST user credentials and get back an auth token for use in subsequent Cypress tests (as recommended in the Cypress docs/examples). Consequently, any code showing a working solution would be extremely helpful for supporting fully automated testing. For now we are manually logging in, copying the auth token, pasting it into our Cypress test config and using it until it expires.

@blex18
Copy link

@blex18 blex18 commented May 22, 2018

@saschwarz I know. I've been there =) Setting the session cookie is trivial. Retrieving the cookie requires a 3rd-party tool. I am not trying to moderate, just pointing out there are better resources to ask for help.

@brian-mann
Copy link
Member

@brian-mann brian-mann commented May 22, 2018

Microsoft should really expose a programmatic API to accomplish this. All of the standard oAuth API's from 3rd party providers do this. I really feel like this must exist in some manner on Microsoft's end. It makes no sense that the only way to authenticate is with a browser's UI.

With that said - you could utilize another tool to login with the UI, extract the login token and then pass that off to Cypress (and effectively then run all the tests). It's cumbersome but would technically work. Albeit, it seems you'll inherit most of the problems related to 3rd party content updating and breaking your tests.

There's not going to be an easier way unless the 3rd party makes it easy.

@rogeralsing
Copy link

@rogeralsing rogeralsing commented May 30, 2018

Microsoft should really expose a programmatic API to accomplish this

Yes, but they have not yet.
So question remains, what is the currently best way to test an Azure AD authenticated site using Cypress?

@pieterdv
Copy link

@pieterdv pieterdv commented May 30, 2018

I created a quick gist of how we are using puppeteer to get the auth tokens, you can find it here: https://gist.github.com/pieterdv/82773fbe036719479d76ab0a4985dc3b

probably the script can be improved but for now it works fine enough

@saschwarz
Copy link

@saschwarz saschwarz commented May 30, 2018

@beanian
Copy link

@beanian beanian commented May 30, 2018

@pieterdv Thanks you! How do you handle the quick redirect to AAD and back again to validate the token when doing a cy.visit with the token set? There seems to be no rhyme or reason to it but because it redirects away from the AUT it breaks cypress.

@saschwarz
Copy link

@saschwarz saschwarz commented Jun 6, 2018

So I bailed on that other project and found @pieterdv had an excellent solution.

I only had to change from localStorage to sessionStorage. I put some wrapper code around his function and created a simple node script to prompt for required values via the command line. I store the values in the json file created so you can re-run it before your tests via --no-prompt option. I added an example of a Cypress custom command for logging in a user and another for making subsequent API calls with the token in the Authorization header:

https://gist.github.com/saschwarz/b7f115ab6a7765ff5e45b9b9461cf895

Suggestions/comments appreciated.

@johnnyreilly
Copy link

@johnnyreilly johnnyreilly commented Jul 10, 2018

Hey guys!

I was mulling this a related problem this weekend. (Auth0 rather than Azure AD) I came up with a solution which seems solid. I've blogged about it here:

https://blog.johnnyreilly.com/2018/07/cypress-and-auth0.html

I'm still very much a Cypress novice and so it's possible my advice here might not be 100% perfect. Please do feel free to set me straight if there's any bad advice in my post. Happy to improve it; I want to spread good advice, not bad.

@grimunit
Copy link

@grimunit grimunit commented Aug 14, 2018

For anyone that comes across this issue and is just trying to get past the authentication to start using cypress and isn't yet trying to actually test their login flow, I finally found out I can just set the tokens with the onBeforeLoad hook of the visit command.

cy.visit('/', {
	onBeforeLoad: (win) => {
		console.log('onBeforeLoad')
		// call any methods you want
		win.localStorage.setItem('AUTH0_ACCESS_TOKEN', 'access-token-here');
		win.localStorage.setItem('AUTH0_ID_TOKEN', 'id-token-here');
		win.localStorage.setItem('AUTH0_EXPIRES_AT', '1534238901425');
	},
});
@thomassuckow
Copy link

@thomassuckow thomassuckow commented Jan 10, 2019

Wondering if something like https://docs.microsoft.com/en-us/rest/api/apimanagement/user/generatessourl is what we are looking for.

@jkosters
Copy link

@jkosters jkosters commented Jan 12, 2019

I updated @saschwarz 's script to make it work for our situation (mostly some selectors).
https://gist.github.com/jkosters/63726a89f8e2be396c4c1675eca90837

So I bailed on that other project and found @pieterdv had an excellent solution.

I only had to change from localStorage to sessionStorage. I put some wrapper code around his function and created a simple node script to prompt for required values via the command line. I store the values in the json file created so you can re-run it before your tests via --no-prompt option. I added an example of a Cypress custom command for logging in a user and another for making subsequent API calls with the token in the Authorization header:

https://gist.github.com/saschwarz/b7f115ab6a7765ff5e45b9b9461cf895

Suggestions/comments appreciated.

@calvinballing
Copy link
Contributor

@calvinballing calvinballing commented Jan 16, 2019

This issue appears to be related to this closed issue: #834

@saschwarz
Copy link

@saschwarz saschwarz commented Jan 16, 2019

@calvinballing Unfortunately, the approaches described in the Cypress best practices documentation/YT videos don't appear to be applicable to the Azure AD login process.

Azure AD doesn't seem to have an API that can be called with a login/password to login a user. They redirect to their website to accept the username/password, which isn't currently supported by Cypress. If anyone has an API-call API for Azure AD please provide your solution!

@jkosters
Copy link

@jkosters jkosters commented Jan 17, 2019

They do have two JavaScript libraries to support said login I believe. This is one. https://github.com/AzureAD/azure-activedirectory-library-for-js

For me the puppeteer solution actually works and we have bigger issues than not logging into sad during testing in the correct way :). But if we manage to carry on like we do this week, I might have time next week to have a look (it's been a while)

@abu-wizata
Copy link

@abu-wizata abu-wizata commented Feb 7, 2019

Unfortunately none of the puppeteer solutions presented have been able to work for us. Even when I'm able to get the login to succeed, as soon as Cypress opens our page it redirects to the login area as if we need to re-authenticate.

A nice unified solution or short term fix to this would be awesome.

@Sefriol
Copy link

@Sefriol Sefriol commented Aug 12, 2020

Maybe not applicable for many, but it seems that you are successfully able to use AD login IF you run tests in Azure Pipelines. Unsure if this would also work from virtual machine in Azure.

We noticed this when we run tests that we expected to fail after certain point, but they did not. When we went through the videos we noticed that tests were able to access AD login page.

Somehow I am not surprised.

@aaronportier
Copy link

@aaronportier aaronportier commented Aug 18, 2020

@Sefriol this is applicable to me. Do you mind sharing that code?
I am looking for a way for Cypress to go to the Microsoft redirect and I will apply username and password. Then get redirected to my website.

@Sefriol
Copy link

@Sefriol Sefriol commented Aug 18, 2020

@Sefriol this is applicable to me. Do you mind sharing that code?
I am looking for a way for Cypress to go to the Microsoft redirect and I will apply username and password. Then get redirected to my website.

Unfortunately I cannot share the code, but you should be able to use Cypress normally to get in to the login site with chrome websecurity disabled if your application is in Azure. Hard to know for sure since I have just tested this in our QA-environment.

You might also need X-frame plugin installed into your testing browser. Since Cypress will eventually be blocked by the X-frame options defined by Microsoft. There are some issues in this repository related to Microsoft Teams login, so you can look into that discussion, but here is also a link that covers it a little bit:

https://medium.com/@you54f/configuring-cypress-to-work-with-iframes-cross-origin-sites-afff5efcf61f

EDIT: Personally I thought this to be too hackish and decided to just mimic the interractions between Microsoft and our backend. We use our own token system anyway and AD is just for user identification.

@aaronportier
Copy link

@aaronportier aaronportier commented Aug 20, 2020

@Sefriol bummer...I figured you might because it's against the Microsoft login page. I set chromsecuriry to false but can not find the login to write against it. Do you maybe have what you use to find the login elements? It looks like a blank screen for me.

@Sefriol
Copy link

@Sefriol Sefriol commented Aug 20, 2020

@Sefriol bummer...I figured you might because it's against the Microsoft login page. I set chromsecuriry to false but can not find the login to write against it. Do you maybe have what you use to find the login elements? It looks like a blank screen for me.

Do you see any X-frame errors in Cypress DevTools? If yes, you should be able to get pass those with the chrome X-frame disable plugin. CSP header disable plugins might help you as well, but I have not really given those a spin.

There might be differences between Microsoft AD tenants since we using the specific one assigned to our company. I have not tried this against different tenants.

@aaronportier
Copy link

@aaronportier aaronportier commented Aug 27, 2020

@TheRobBrennan
Copy link

@TheRobBrennan TheRobBrennan commented Sep 2, 2020

Yeah this issue is super frustrating. At a high level, I want my Cypress E2E tests to function with a real response from Azure. I have an app using react-adal, and even if I store the token in localStorage or sessionStorage after successfully receiving an authorization response from Azure, subsequent cy.visit() calls simply ignore the token.

There has to be an easier way to do this, no? It's not possible to have E2E tests actually sign in against a valid Azure account and work with an app? The app requires all kinds of live data - mocking is not an option.

Working around it defeats the purpose of the E2E test, right? A known account should be able to sign in and then run the suite.

@ng-marcus
Copy link

@ng-marcus ng-marcus commented Sep 2, 2020

With SharePoint using so many tricks, invisible frames, cookies and the like to authenticate against Azure AD, we failed to be able to test our Spfx app with Cypress when we started using MS Graph too.

This is in no way meant as a criticism of Cypress but what worked for us to was to switch to Puppeteer and Jest. I run one task that clicks through a (non MFA) login and dumps cookies to a file. All my other tests then just load that cookie file and have full access to SharePoint, Graph and Azure AD protected functions. For CI it's easy to just run that cookie grab and then run the test suite.

@TheRobBrennan
Copy link

@TheRobBrennan TheRobBrennan commented Sep 2, 2020

Thanks! Yeah this is definitely a challenge, for sure. Those resources were helpful, although I'm still coming up short. Much appreciated, though

@Sefriol
Copy link

@Sefriol Sefriol commented Sep 2, 2020

Thanks! Yeah this is definitely a challenge, for sure. Those resources were helpful, although I'm still coming up short. Much appreciated, though

Can you also specify your problem a little bit more. From my understanding, adal should keep the token updated when you set it. At which point does this break? What does adal respond when it requests a new token?

(Our solution uses adal too, but we use our site specific token since we do not really need AD for anything else than identifying the user for us.)

@aaronportier
Copy link

@aaronportier aaronportier commented Sep 3, 2020

LMFinney added a commit to LMFinney/active-directory-javascript-singlepageapp-angular-dynamic-config that referenced this issue Sep 3, 2020
This code is adapted from https://gist.github.com/csuzw/845b589549b61d3a5fe18e49592e166f, which itself was adapted from cypress-io/cypress#1342.
Unfortunately, there is not a standard way to do AD Azure logins from Cypress.
@munozdaniel
Copy link

@munozdaniel munozdaniel commented Oct 2, 2020

@blex18 as a work around for now I use puppeteer to do the login in microsoftonline, then I set the variables that are in puppeteer localstorage in cypress localstorage and from there on i can continue. Not an ideal workflow but it works

Can you provide an example repository?

@muzahir-12
Copy link

@muzahir-12 muzahir-12 commented Oct 2, 2020

@smithapatil14
Copy link

@smithapatil14 smithapatil14 commented Oct 2, 2020

This solution mostly worked for me . It is a great article https://mechanicalrock.github.io/2020/05/05/azure-ad-authentication-cypress.html

@aaronportier
Copy link

@aaronportier aaronportier commented Oct 4, 2020

@dragon788
Copy link

@dragon788 dragon788 commented Oct 19, 2020

I'm trying to sign-in so I can do a cy.visit to an ASP.NET Core application running on an Azure App Instance that's internally configured for Azure AD.
in a custom Cypress command I'm attempting this(utilizing the clientID, tenantID & clientSecret) that are in the ASP.NET Core's "AzureAd" in appSettings.json.

Here's the code snippet:

cy.request({
    method: "POST",
    followRedirect: false,
    url: `https://login.microsoftonline.com/${Cypress.config('tenantId')}/oauth2/token`,
    form: true,
    body: {
        grant_type: "client_credentials",
        client_id: Cypress.config("clientId"),
        client_secret: Cypress.config("clientSecret"),
        resource: Cypress.config("clientId"),
    },
}).then((response) => {
    const aadToken = response.body.access_token;

I get back what looks like a valid Azure AD token. Now the question is what do I do with it? When I inspect the cookies for the domain when I manually have logged into the application, I notice there is a cookie called '.AspNetCore.AzureADCookie' with a token that is different from the one I'm getting back from this code.

Please someone give me some pointers.

If you can enable the ROPC (resource owner password credentials) for your application endpoint/tenant you can use this, we ended up just using B2C for automated test accounts and AzureAD is only tested by real users so that we didn't have to open the internal AD which is quite large to potential credential stuffing attacks.

What we ended up doing in our implementation was a cy.get('') of our baseUrl to instantiate the LocalStorage and SessionStorage for our domain. Then we used a very similar snippet to the above code block a cy.wrap around the response and then used the cypress-localstorage plugin to cy.setLocalStorage('access_token', response.body['access_token'] using a cy.get to unwrap the wrapped response.

If you aren't seeing what you expect in the response, you might need to specify your scope and desired response type.

        scope: `openid profile ${azureClientId} offline_access`,
        response_type: 'token id_token'
@Sefriol
Copy link

@Sefriol Sefriol commented Oct 21, 2020

You probably meant cypress-localstorage-commands.

Just a reminder to anyone trying to save access token into localstorage that Cypress will clear localstorage after every test. So you need to either login again after every test or use functions to save localstorage. (There is some movement to get this user configurable, but that's beyond this topic right now)

For latter, you can use the npm package linked above, or redefine localstorage clear function within Cypress:

//cypress/support/commands.js
const KEYS_IGNORED = [
  'access-token'
]

Cypress.LocalStorage.clear = (keys) => {
  // Specific clear
  if (keys !== undefined && Array.isArray(keys) && keys.length > 0) {
    keys.forEach(key => window.localStorage.removeItem(key))
  } else {
    // Full clear
    if (window.localStorage.length > 0) {
      Object.keys(window.localStorage)
        .filter(key => !KEYS_IGNORED.includes(key))
        .forEach(key => window.localStorage.removeItem(key))
    }
  }
}
@dragon788
Copy link

@dragon788 dragon788 commented Oct 21, 2020

You are correct, I forgot the full name of the package but that is the one.

We use the same method as outlined in the mechanicalrock post, and by putting the login in the support files it will get evaluated and executed before/during every test, so we get a fresh token and don't have to worry whether saving an access token between tests has caused a flaky failure due to the token expiring during a long running test, or if a test will get unexpected successes/failures due to incorrect permissions like going from a wide access user like an admin to a limited access user like a guest or vice versa, and we don't have to remember to clear the localStorage between those tests, which would be especially tricky if you are running with --parallel across multiple nodes.

@idubrov
Copy link

@idubrov idubrov commented Dec 31, 2020

In our case, pushing tokens / credentials into the application wasn't enough: in some environments we have another protection around our deployments which uses OAuth2 proxy + Google Login.

In short, we really need to log into Google and then let the application do the silent Auth0 login (and pass through the OAuth2 proxy where necessary). Sure, we could tweak our deployments and application, but I don't really like the idea of having some special behavior just for test purposes.

Locally running application? Maybe. I can even drop auth altogether since both frontend and backend are running locally against local database anyways.

Deployed environment? No, it should behave as close to production as possible (another reason why it would be hard to do following https://auth0.com/blog/end-to-end-testing-with-cypress-and-auth0/ article: default behavior for Auth0 React integration is to use "in-memory" for storing tokens, which is hard to hack into. I don't want to switch it to local storage.

The first part, google login, could be done via cypress-social-logins, which uses puppeteer. However, it does not quite solves the issue: it gives us cookies, but we need to set those cookies for google domains!

I tried to find if there is any way to make Chrome running under Cypress to load cookies for other domains. cy.setCookie doesn't work (I think, because of a different domain).

So in the end I came up with this abomination (perhaps, one of the worst hacks I ever did): https://gist.github.com/idubrov/d8b06800bed48ebb41465a219a7908a1

Idea: set cookies by intercepting server requests and replacing them with ones we control.

Implementation: it's not as easy as it sounds! Few gotchas:

  1. Just doing redirect doesn't work because of redirect limit (and we need to set ~23 cookies; I haven't analyzed which ones do I really need, though).
  2. Doing redirect via HTTP response doesn't work either. First, if I redirect all the way through, Cypress seems to follow redirects by itself & they don't get to the browser. The response with Set-Cookie has to be 200 response. Second, I cannot end on a different URL than my application domain because of https://docs.cypress.io/guides/guides/web-security.html#Same-superdomain-per-test. I also have to start with "my" domain. Hence this scheme with two redirects: visit "my" domain, redirect via JavaScript to fake "google" domain which sets cookie, redirect back to another URL on "my" domain.
  3. Some gotchas around cookies: SameSite=Lax (default) doesn't work (Chrome rejects it). I haven't figured why, maybe, because of redirects (browser says that it can only set Lax cookie on the same top navigation or something)? So I had to forcefully make all the cookies ; Secure; SameSite=None.
  4. Cypress does not allow setting multiple cookies at once 😭 so I have to repeat the process for each cookie.

Well, I got it working, but I don't have much trust in this. Looks very brittle.

P.S. Now, as unsolicited opinion nobody asked me (which I'm sure was expressed many times in this ticket, feel free to ignore; I just need to vent a bit 😛) I would rather have an option to just make Cypress visit and "test" third-party site normally, even though it is considered a bad practice. The alternative, it seems, is to depend on internal details or special configuration (like, we don't even have Auth0 database users -- only social login), which, arguably, could be worse.

P.P.S. #944 (comment) looks very optimistic!

@fizza-aamir
Copy link

@fizza-aamir fizza-aamir commented Jan 13, 2021

I would like to share this video link , i think its helpful.
UI testing Azure AD protected single page applications with Cypress - Joonas Westlin
https://www.youtube.com/watch?v=OZh5RmCztrU&ab_channel=Cypress.io

@blex18
Copy link

@blex18 blex18 commented Jan 13, 2021

I would like to share this video link , i think its helpful.

Very good and is helpful indeed. It's 50 min long but well worth the time if it fits to your usecase. Joonas promised to sum it up in an article which should be even more valuable.

The presentation describes a scenario of an SPA which holds both access and refresh tokens clientside. In this particular case he recommends to use ROPC flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc . Only for testing purposes of course.

It won't work if you keep the refresh tokens serverside and use it to access 3rd party resources, yet in some simpler cases it's a great approach to reliably log in with Azure AD.

@MikePopov
Copy link

@MikePopov MikePopov commented Jan 21, 2021

I would like to share this video link , i think its helpful.
UI testing Azure AD protected single page applications with Cypress - Joonas Westlin
https://www.youtube.com/watch?v=OZh5RmCztrU&ab_channel=Cypress.io

I used that approach and successfully get Tokens, but items in localStorage not like in the video they look like a msal.tokenId and {authority etc. I build similar items and put them to localStorage but my application still redirects me to the login.microsoftonline.com. I have no idea how to solve that problem

@khvirtru
Copy link

@khvirtru khvirtru commented May 14, 2021

Hi Cypress team,

I've got a scenario to test Office JS Add In, I am evaluating for the team if it is possible to use Cypress at all.

To test the AddIn, I need to login to outlook.office.com, so the AddIn can interact with the contents using Office JS API.

So:

  1. I login with Puppeteer, to get all token data,
    image

  2. Then I use Cypress to set token data, however, I am blocked here as described in the screenshots, the token belongs to a separate domain URI. Any advices will be appreciated. Thanks!
    2nd_session_storage_object_not_available_if_not_logged_in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet