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

Comments

8 participants
@jedateach
Copy link

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

@brian-mann

This comment has been minimized.

Copy link
Member

commented Apr 24, 2018

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.

@katerynae

This comment has been minimized.

Copy link

commented Oct 11, 2018

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

This comment has been minimized.

Copy link

commented Oct 11, 2018

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

This comment has been minimized.

Copy link

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');
    })
  })
})
@cypress-bot

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

commented May 1, 2019

My mistake - sorry for the confusion!

@cypress-bot

This comment has been minimized.

Copy link

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
You can’t perform that action at this time.