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

ensureUrl failure (potentially due to corporate proxy usage) #1541

Closed
jedateach opened this issue Apr 4, 2018 · 10 comments · Fixed by #3531
Closed

ensureUrl failure (potentially due to corporate proxy usage) #1541

jedateach opened this issue Apr 4, 2018 · 10 comments · Fixed by #3531

Comments

@jedateach
Copy link

jedateach commented Apr 4, 2018

Current behaviour:

Cypress could not verify that the server set as your 'baseUrl' is running:

  > https://example.com

Your tests likely make requests to this 'baseUrl' and these tests will fail if you don't boot your server.

Desired behavior:

Tests run after successful ensureUrl check

How to reproduce:

Run tests over proxy.

Or this might be to do with the fact our baseURL serves 403 responses - which is normal behaviour for us. Our tests query sub-urls, which return 200 responses. This theory is inconsistent with the http://example.com call failing the ensureUrl check.

Our hunch is that node's net.connect method, used in the ensureUrl check isn't respecting proxy settings.
https://github.com/cypress-io/cypress/blob/master/packages/server/lib/util/connect.coffee#L10

Additional Info (images, stack traces, etc)

We are able to run via the Cypress UI, but with a warning message in the UI.

When I commented out the following ensureURL check, tests were able to run.

  _this._server.on("upgrade", onUpgrade);
          _this._server.once("error", onError);
          return _this._listen(port, onError).then(function(port) {
            return Promise.all([
              httpsProxy.create(appData.path("proxy"), port, {
                onRequest: callListeners,
                onUpgrade: onSniUpgrade
              }), fileServer.create(fileServerFolder)
            ]).spread(function(httpsProxy, fileServer) {
              _this._httpsProxy = httpsProxy;
              _this._fileServer = fileServer;
              _this._baseUrl = baseUrl;
              // if (baseUrl) {
              //   return connect.ensureUrl(baseUrl)["return"](null)["catch"](function(err) {
              //     if (config.isTextTerminal) {
              //       return reject(errors.get("CANNOT_CONNECT_BASE_URL", baseUrl));
              //     } else {
              //       return errors.get("CANNOT_CONNECT_BASE_URL_WARNING", baseUrl);
              //     }
              //   });
              // }
            }).then(function(warning) {
              _this._onDomainSet(baseUrl != null ? baseUrl : "<root>");
              return resolve([port, warning]);
            });
          });
        };
      })(this));
  • Operating System: RHEL7
  • Cypress Version: 1.4.2
  • Browser Version: Chome 60
  • Node Version: 8.8.0
@jedateach jedateach changed the title ensureUrl failure ensureUrl failure (potentially due to corporate proxy usage) Apr 4, 2018
@jennifer-shehane jennifer-shehane added the stage: needs investigating Someone from Cypress needs to look at this label Apr 4, 2018
@brian-mann
Copy link
Member

This is correct, net.connect does not respect proxies. We'll need to switch to using a regular HTTP request when net.connect fails or when proxies are set.

@knaumenko
Copy link

I am getting the same error when running my tests in circleCI and updating env variables didn't help. Are there any progress on this?

@cgalbiati
Copy link

I am getting the same error when running my tests in circleCI and updating env variables didn't help. Are there any progress on this?

To elaborate on @katerynae's comment (I am a teammate), we started getting the error when we switched from a url that was redirected to a cdn using cname rules, to one that was proxied through cloudflare and an nginx server.

@rsmets
Copy link

rsmets commented Oct 12, 2018

I have been using a workaround of just passing an environmental variable effectively replacing the baseUrl setting in the cypress.json. However I think a side effect of doing so is upon first opening a test using the test runner the initial check is made on localhost (and subsequently tests are run) then the browser reloads and all but the first test is reran which is what the dashboard reads as the result. This stutter step, so to speak, has had averse effects on tests as one can imagine. Below is an example to reproduce. Please open the console with preserve log checked. In this example the testUrl value is not used but in reality is. I have posted this a separate bug ticket here #2602

var randomstring = require("randomstring");
const BASE_URL = Cypress.env('testUrl'); // until https://github.com/cypress-io/cypress/issues/1541 is resolved using testUrl env var instead of baseUrl

var randomString;
describe('bug highlight', function () {
  before(function () { 
    randomString = randomstring.generate();
    console.log('randomString1', randomString);
  })

  context('bug', function () {
    it('post', () =>{
        console.log('randomString2', randomString);
        return cy.request({
            method: 'POST',
            url: `https://e.deployads.com/e/whatismyip.com`, //non-example case I would use var BASE_URL defined above via an env variable 
            form: false,
            body: {"jsr":{"_count":1,"bdl":"7133","msg":"Okay","u":"https://www.whatismyip.com/what-is-my-public-ip-address/","pv":`${randomString}`,"sid":"jn6d3c0k2juz91","r":"https://www.google.com/","sta":200,"tas":1539368968738,"bld":17252,"s":"whatismyip.com","uid":"jn6d3c0k2juz91","typ":"im","cfdt":"D","rt":115,"_type":"jsr"}}
        }).then((response) => {
            console.log('in request response');
            cy.expect(response.status).to.eq(200);
        })
    })

    it('visit', () =>{
        console.log('randomString3', randomString);
        cy.visit('https://google.com');
    })
  })
})

@flotwig flotwig mentioned this issue Feb 20, 2019
38 tasks
@cypress-bot cypress-bot bot added stage: work in progress and removed stage: needs investigating Someone from Cypress needs to look at this labels Mar 1, 2019
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Apr 1, 2019

The code for this is done in cypress-io/cypress#3531, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@supasympa
Copy link

supasympa commented Apr 30, 2019

Please could someone confirm that version 3.2.0 has fixed this issue?
I'm trying it and see the same behaviour as I did previously with version 3.1.*

Running on a different network without proxies, I don't have the same issue.

@Lakitna
Copy link
Contributor

Lakitna commented Apr 30, 2019

Latest release was 3/15/2019 https://github.com/cypress-io/cypress/releases
This issue was closed on 4/1/2019

So this is not a part of 3.2.0.

@jennifer-shehane
Copy link
Member

jennifer-shehane commented May 1, 2019

This issue is still pending release - as indicated by this comment #1541 (comment) and the label of stage: pending release.

This is not part of 3.2.0. We will comment on this issue as soon as it is released.

@supasympa
Copy link

My mistake - sorry for the confusion!

@cypress-bot
Copy link
Contributor

cypress-bot bot commented May 17, 2019

Released in 3.3.0.

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

Successfully merging a pull request may close this issue.

8 participants