使用cypress的e2e测试中的身份验证错误:chrome-error://chromewebdata [英] Error with authentication in e2e tests using cypress: chrome-error://chromewebdata



我正在使用cypress为我的UI编写E2E测试(请注意,这是PowerBI报告,因此是一种特殊情况).当我用公开报告进行测试时,它可以正常工作.但是,当它是私人PBI报告时,我在登录部分上遇到了麻烦.经过一番研究,我发现这种方法对于基于Azure AD的身份验证很有用,并在我的commands.js文件中添加了此登录功能:

I'm using cypress for writing E2E tests for my UI (Note that it's a PowerBI report, hence it's kind of special case). When I am testing with a public report, it works fine. But when it's a private PBI report, I am having trouble with login part. After some research, I found this approach promising for Azure AD based auth, and added this login function in my commands.js file:

Cypress.Commands.add('login', () => { 
        method: 'POST',
        url: 'https://login.microsoftonline.com/{TENANT}/oauth2/token',
        form: true,
        body: {
            grant_type: 'client_credentials',
            client_id: CLIENT_ID,
            client_secret: CLIENT_SECRET,
            // resource: RESOURCE
        header: {
            'Content-Type': 'multipart/form-data'
    }).then((responseData) => {
        if (responseData.status === 200) {
            window.sessionStorage.setItem("adal.idtoken", responseData.body.access_token);
            window.sessionStorage.setItem("adal.token.keys", CLIENT_ID + "|")
            window.sessionStorage.setItem(`adal.expiration.key${CLIENT_ID}`, responseData.body.expires_on)
            window.sessionStorage.setItem(`adal.access.token.key${CLIENT_ID}`, responseData.body.access_token)
        } else {
            console.log("error retrieving token")


Note that the Client ID and secret are correct and have permission to access the powerbi report. I also tested the token generated, and the sessionStorage variables, and all seem to be assigned correctly. Now, in my test:

describe("E2E Tests", () => {
    beforeEach(() => {
    it("Sample Test 1", () => {


And I am seeing in the cypress test runner that, even though login has been called in beforeEach, while visiting the powerbi report, it still redirects to https://login.microsoftonline.com url with a different client id as query param, and since the superdomains of powerbi report and redirected urls are different, it gives chrome-error://chromewebdata error(I guess that's the reason). Hence wondering, how to login to a website in cypress tests backed by azure ad auth.


Also, might be unrelated, but seeing one more error in the console:

Refused to display 'https://powerbi-report-url.com' in a frame because it set 'X-Frame-Options' to 'deny'.

切换到Edge不会产生chrome webdata错误,但URL的cy.visit仍然超时并给出HTTP 431错误(请求标头过长)并且无法进行身份验证.

Edit 1: Switching to Edge doesn't give the chrome webdata error, but still the cy.visit to the URL times out and gives HTTP 431 Error(Request header too long) and couldn't authenticate.

编辑2(有关Auth错误的更多详细信息):使用客户端凭据生成令牌时,我正在获取令牌,并看到它已存储在会话存储中,但是赛普拉斯测试未选择相同的令牌来授权访问到PowerBI报告.因此,基本上甚至认为该cookie都存在,可以对请求进行身份验证,对Power BI访问的请求仍会重定向到login.microsoftonline.com/common/oauth2/authorize?client_id= {与上述POST中使用的客户端ID不同的客户端ID致电}

Edit 2 (More Details about Auth Error): While generating the toke using client credentials, I am getting the token, and see it's stored in the session Storage, however the cypress tests are not picking the same token to authorize the visit to PowerBI report. So, basically even thought the cookie exist to auth the request, the request to Power BI visit still redirects to login.microsoftonline.com/common/oauth2/authorize?client_id={a different client ID from what I am using in the above POST call}


Whereas, while using username/password; getting this error: "error": "interaction_required", "error_description": "AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access "error_codes": [50079]


目前(20年4月17日),这可能与赛普拉斯团队的公开问题有关: https://github.com/cypress-io/cypress/issues/4220

At this moment (17-Apr-20), this might be related to an Open issue with the Cypress team: https://github.com/cypress-io/cypress/issues/4220


For me particularly, I used to have one super-domain having this error with the previous version 4.3.0 but now with 4.4.0, I get more domains having same issue.


Current workaround: Roll back to previous version and run via Edge (which is based on Chromium anyway).


登录 关闭
发送“验证码”获取 | 15天全站免登陆