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.
}
})
Related
My NuxtJS applications makes HTTP request to a backend API. I am using nuxtjs/axios pluging to make these requests. I have configured base URL for API in nuxt.config.js like below
axios: {
baseURL: process.env.BASE_URL,
},
In Local, I have a .env like below
BASE_URL=http://localhost:8080
On AWS ECS Container, I have declared environment variable with
Key: BASE_URL and Value: https://example.com
On running the application following happens
When application is server-side rendered, base URL for API is resolved correctly e.g https://example.com/previews
When application is client-side rendered, base URL for API is not resolved to https://example.com but rather to the same IP address that my web application is accessible on.
So, what I understand might be happening is, that the process.env.BASE_URL is not getting passed from the server-side(NodeJS server) to client-side(Web Browser). Hence it is falling back to the application's IP address.
Any idea why such a behavior and how to pass the environment variable to client-side as well? Or what might be causing this.
Thanks.
TestCafe devs: Thanks for creating a great, easy to use product!
I'm using testcafe to do full end-to-end tests on my electron app, which is sending XHRs with most endpoint URLs having the file:// scheme and some others an API that we control.
I fixed the CORS issues (testcafe proxy was responding with the 222 code) with the file:// URLs by starting up the Http-server npm package with --cors turned on.
My current problem is that when my app sends the XHR to the API, nothing I seem to do resolves the problem. I'm not looking to mock the API requests. When not running my app inside testcafe instances, both file:// and API requests have no issues.
Is there a (straightforward) way to solve this? (Also, is there a similar solution for the file:// requests without having to create a webserver?) I'm assuming this issue is common, and I have looked thru the Github issues for both testcafe and testcafe-hammerhead as well as the Recipes page. I've also tried to create a request hook, but I'm still getting the 222 response code.
Here is my custom hook:
class MyHook extends RequestHook {
constructor(requestFilterRules) {
super(requestFilterRules, {includeHeaders: true, includeBody: true});
}
onRequest(event) {
event.requestOptions.headers['Origin'] = 'file://';
console.log(event);
}
}
I'm assuming that all I had to do was change the Origin: header to something that my API accepts, per the above code. (I'm guessing that the presence/absence of the includeHeaders/include body properties or the response method in the above code do not have an effect here, but I'm not sure.)
Thank you!
When using history mode in vue-router the documentation is suggesting a pretty dodgy way to get around some of the limitations it has.It suggests a server-side configuration that catches all URLs that could be a client-side route and rewriting to root (/) so the client-side app is delivered. And then another catch-all route to a 404 component in the client-side router if no routes match.
Problem is, this will mean your server is returning 200 OK status codes to crawlers/indexers for basically every URL, specifically ones that don’t technically exist.
My thoughts so far:
Use IIS <rewriteMap> to list the valid client-side route patterns I have and use that for matches instead of a catch-all on everything not a file/dir.
Problem: pain to manage in tandem with client-side routes.
Routes defined in server config and handed to client-side router via an api endpoint for registration
Problem: setting up an API when you just want to host a static app is a pain.
Any other suggestions?
I am using a dotNet core project to host an Angular2 application. I am having problems with the deep linking URLs.
For example, when I initially browse to http://localhost:54675/app/dashboard I get a 404 error because there is nothing to serve at app/dashboard. I want to actually load index.html (the angular app) and then have routing take me to app/dashboard.
I use the code below to redirect to index.html if I get a 404 and the URL has no extension.
app.Use(async (context, next) =>
{
await next();
if (context.Response.StatusCode == 404 && !Path.HasExtension(context.Request.Path.Value))
{
context.Request.Path = "/index.html";
await next();
}
});
This will not work when I have a routing with parameters that include JSON such as:
http://localhost:54675/app/repairReturnListing;filter=%7B%22Status%22:[%22AWP%22]%7D
My if statement ignores requests with an extension and Path.HasExtension throws and ArgumentException on this path. The path resolves to this on the server side:
"/app/repairReturnListing;filter={\"Status\":[\"AWP\"]}"
I removed the 'HasExtension' condition and then I get a lot of console errors looking for map files that I don't host. Like this:
Failed to parse SourceMap:
http://localhost:54675/lib/js/rxjs/operator/timeout.js.map
I don't get these errors in the network tab. I think this is something used for debugging.
My angular2 app uses HTML5 routing. I use static files to serve the angular2 application. I have one webApi controller that returns some configuration data (the rest of the data is returned by another webApi project).
Waiting on a 404 and redirecting seems like a work-around and it's not even working.
Any suggestions on the best way to do this?
Check out ng2-kestrel-appserver http://tattoocoder.com/kestrel-as-a-static-server-for-angular/
Does exactly what you're looking for. It was created for RC2 but should work for the current release with few or no changes.
I have a web application generated by the Angular Fullstack Generator. If the ExpressJS server gets a request for an unknown URL for some specific directories, it will return a 404:
app.route('/:url(api|auth|components|app|bower_components|assets)/*')
.get(errors[404]);
For all other unknown routes, it just redirects to the homepage:
app.route('/*')
.get(function(req, res) {
res.sendfile(path.resolve(app.get('appPath') + '/index.html'));
});
Is this a good idea? The reason I ask is because Google has reported my site as maybe being hacked. It keeps trying to fetch URLS like http://andrewkoroluk.com/survival-games-1-e7733-map, and when it gets a 200 OK response, it marks the site.
The RFC of HTTP states you must return 404 when not found.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5
This is not good or bad practice, this is mandatory