Including auth credentials in baseUrl causes browser to never connect in headless mode #1598
Comments
|
Does the run work when running |
jennifer-shehane
added
the
stage: needs information
|
Yes, |
|
Yeah, I don't see why this should be happening from the information provided. Could you run |
|
Here's the log |
|
|
Yes, the app requires basic auth credentials, they are passed in the url. |
|
I had a similar issue when I updated from 1.3.0 to 2.1.0. I removed the auth credentials from the baseUrl and pasted them into the options of Before After cy.visit('/', {
auth: {
username: 'name',
password: 'secret',
},
});Now it works for me. Maybe this is helpful. |
|
@IgorCherednyk were you able to try the workaround as described by @fbring ? |
jennifer-shehane
added
stage: awaiting response
|
Hi, I had the same issue as you describe. So after investigation, my problem was coming from I used to have: on('before:browser:launch', (browser = {}, args) => {
// console.log(browser, args) // see what all is in here!
// browser will look something like this
// {
// name: 'chrome',
// displayName: 'Chrome',
// version: '63.0.3239.108',
// path: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
// majorVersion: '63'
// }
// args are different based on the browser
// sometimes an array, sometimes an object
if (browser.name === 'chrome') {
args.push('--headless')
args.push('--disable-dev-shm-usage')
// whatever you return here becomes the new args
return args
}
})and it was working totally fine before 2.X. But with 2.X chrome can't open. However if I remove this code, everything run correctly. So I think there is a breaking change there. Maybe you have similar problem ? problem of the code was So does there is an other way to put chrome in headless ? |
|
@AyWa No, there is currently not a way to run Chrome headlessly in Cypress. We could probably have a better error for this situation. |
|
Got it, indeed could be cool, if cypress throw an error, or maybe even a little help like: |
jennifer-shehane
added
stage: ready for work
|
Observations: If
Here’s my solution: Cypress.Commands.overwrite("visit", (originalFn, url, options) =>
originalFn(url, {
auth: { username: "user", password: "pass" },
...options,
})
); |
jennifer-shehane
changed the title
jennifer-shehane
added
the
type: regression
|
I had a similar issue. Below workaround works just fine. Before {
"baseUrl": "https://name:secret@domain.io"
}In Test cy.visit();After {
"env": {
"url": "https://name:secret@domain.io"
}
}In Test cy.visit(Cypress.env("url")); |
|
Same behavior here : Steps to reproduce:Please use this repo https://github.com/spras/issue-cypress to reproduce this behavior. There're a docker-compose with an ultra simple webapp, with BASIC Authentification.
Start the website : Run in headless mode the tests with baseUrl : When i run the same command without the baseUrl parameter, there's no timeout, of course the second test fail in 404. When i run the same, with the baseUrl, in the UI, everything is OK : VersionsCypress 3.2.0 |
|
Having similar problems here, I'm trying to run Cypress Cypress version: 3.5.0 |
|
I've verified that the issue as detailed with a reproducible example by @spras that was happening in Cypress 3.2.0 has been fixed in Cypress 3.5.0 with the Electron upgrade #4720 If you're facing this issue, please you run Cypress in our latest version. If your issue is still happening, please open a new issue with a reproducible example, since we are considering this exact use case resolved. |
jennifer-shehane
removed
the
stage: ready for work
Current behavior:
After update of cypress from 1.4.2 to 2.1.0 browser never connected in headless mode.
Console output
Steps to reproduce:
removed folders:
node_modules
cypress
removed @ types/cypress from package.json
changed cypress version in package.json from 1.4.2 to 2.1.0
Then installed dependencies and started tests in default headless mode
npm install
cypress run
Versions
OS: Windows 10 / macOS High Sierra v 10.13.4
Cypress: 2.1.0
same behavior on Windows and macOS
package.json
cypress.json
{ "integrationFolder": "dist/specs", "reporter": "mochawesome" }The text was updated successfully, but these errors were encountered: