Does Cypress support multidomain testing in the same test?
I am getting the below error while navigating to the different domain:
The new URL is considered a different origin because the following parts of the URL are different:
superdomain
You may only cy.visit() same-origin URLs within a single test.
Related
We have configured multiple base sites in our setup, with different URL Patterns as matchers (think of "/<country/", where different countries are mapped to different base stores). This works so far. But if a user enters the URL without a country part (for example just "/" as path), it will just show an empty page. The following error will be thrown in the browsers console:
Error: Uncaught (in promise): Error: Error: Cannot get base site config! Current url (https://some-host.example.com/) doesn't match any of url patterns of any base sites.
Is there any way to register a handler to handle this case correctly? e.g. redirect the User to some base site
I am testing a Gatsby app/site with Cypress. It makes a number of calls to an api from a variety of pages. We have taken the decision to stub and mock all these requests, so our tests should never hit our live api.
I was looking for a way to have Cypress error if a request to any of our API endpoints was made that wasn't stubbed, and I found the force404 config param (docs) for cy.server which enforces a 404 to be returned for any routes that aren't stubbed. This works well, but actually too well. Gatsby uses XHRs internally to preload other pages (amongst other things) and this causes all those to return 404s as well, effectively breaking the app.
Is there a way to configure cy.server to only return 404s from routes that aren't stubbed that are on a particular domain. For example if our api domain is api.example.com. Is there a way to configure cy.server to return a 404 only for requests to api.example.com that are not stubbed, while leaving requests to other domains, or the same domain untouched.
Did you try whitelisting? You could add a rule here to whiletlist all domains that are not your server's
https://docs.cypress.io/api/commands/server.html#Change-the-default-whitelisting
cy.server({
whitelist: (xhr) => {
// specify your own function that should return
// truthy if you want this xhr to be ignored,
// not logged, and not stubbed.
}
})
I'd like to use window.location.href in the tool codesandbox.io. This is because I want to do a test with a hard page load occurring. I'm running into an issue however.
location.href = "http://www.google.com"
I get this error:
Mixed Content: The page at 'https://codesandbox.io/s/lingering-bird-nyvfi' was loaded over HTTPS, but requested an insecure resource 'http://www.google.com/'. This request has been blocked; the content must be served over HTTPS.
Example: https://codesandbox.io/s/locationhref-usage-nyvfi (see src/index.ts and open Dev Console)
How do I accomplish this the ability to simulate a page load, in the fake virtual browser?
I think it may be possible once the security criteria are met; which is limiting.
Use HTTPS (Avoid mixed content)
Use same origin
Thus this works:
window.location.href = "https://www.codesandbox.io/docs";
I'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.
I'm keeping the backend API as a separate project from the frontend HTML5 app consuming it. I'm using Yeoman for the frontend development. Yeoman runs on localhost:3501 and the backend on localhost:3000. When I make the API request from the browser (using AngularJS's $http), I hit the same origin policy:
XMLHttpRequest cannot load http://localhost:3000/venues. Origin http://localhost:3501 is not allowed by Access-Control-Allow-Origin.
AFAIK, same origin policy should kick in only when making request across different domains. Why is it whining when we do a request from localhost to localhost (albeit to different port)?
How can I make this work and will this cause problems in production?
The ports also count for cross domain requests, therefore http://localhost:3000 and http://localhost:3501 are 2 different domains (from browser's point of view).
If you need both applications (client and backend) to run on different ports, consider using http://enable-cors.org/
According to W3C, "An origin is defined by the scheme, host, and port of a URL", so the different port is causing your problems.
Two possible solutions:
CORS (Cross Origin Resource Sharing)
Using JSONP requests
Both would require changes to your backend (I'm not familiar enough wo. CORS would probably mean the least changes to your frontend (I think AngularJS supports it out-of-the-box).