I have been trying to intercept a server request using Cypress' intercept method.
I have noticed that Cypress can intercept requests made through the front-end/browser, however, the intercept method doesn't work if I make a request directly to the back-end server.
Let me clarify what I mean:
One thing is intercepting a request that the front-end/browser makes to the back-end server.
Another thing is intercepting a call that doesn't use the browser but calls directly the back-end endpoint.
For example:
I can create a user using the front-end interface
or I can create a user calling the back-end endpoint directly (directly calling the server).
Coming back to my question. Is there a way to intercept a call that was made directly to the back-end endpoint?
This is what I have tried so far:
I wrote a regex to intercept api/v0/customers
I then made a request to http://locahost:5440/api/v0/customers (which is the URL of the server)
Finally, I waited for the request to happen
Timeout request using Cypress intercept method
cy.intercept(/^\/api\/v0\/customers\/$/).as('createCustomer');
cy.request(createCustomer(customerData, headers));
cy.wait('#createCustomer').then(({ status, body }) => {
const customerId = body.customer_id;
console.log(body);
expect(status).equal(201);
});
Here's the problem: There was a timeout error.
As you can see in the image, I'm making a request to http://locahost:5440 which is the server URL. NOTE: I made sure the server was up and running.
The regex is also correct and it will match the endpoint http://locahost:5440/api/v0/customers
I suspect that intercept only works for requests being made through the browser. Is this assertion correct? I couldn't find this answer anywhere in the Cypress docs.
Is there a way for me to intercept a call being made directly to a server (not using the browser)?
You don't have to intercept the requests you explicitly make with cypress, just use .then to get the response, like this:
cy.request(createCustomer(customerData, headers)).then((response) => {
const customerId = response.body.customer_id;
console.log(response.body);
expect(response.status).equal(201);
});
Reference: https://docs.cypress.io/api/commands/request#Yields
Related
I have an xAPI content made by storyline I want for the statement to be sent to a webapp instead of the LRS.
this webapp is developped using laravel, and user should be authenticated with email and password to use it.
what I did to send the statement to this app:
1.in the webapp I created an API endpoint route that use POST method.
2.in the xAPI wrapper I changed the endpoint in the configuration to the route I made in the webapp.
const conf = {
"endpoint":"here I added my api endpoint route of the webapp",
"auth":"Basic " + toBase64(""),
}
now whith any interaction with the content where a statement should be sent the request making cors error like in the picture down, I think this is authentication error, how can I add my authentication credentials to the xAPI wrapper?
Your non-LRS LRS is probably not handling preflight requests which are necessary for CORS handling. Most common LRSs will handle those requests appropriately since they expect to be accessed from additional origins. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests
Also note that you'll likely run into issues unless you also handle state requests.
Additionally unless you are requesting the credentials from the user during runtime then hard coding the credentials into the package isn't a great idea from a security perspective.
I set up a Cloudflare worker to redirect to our API gateway since we don't have control of the DNS and can't just set up a CNAME. The redirect works and it passes along the body and all the headers except Authorization. It receives it, and when I look at the worker console it lists it as redacted. It also redacts the user_key param I'm passing but it passes that through.
const base = 'https://myurl.com'
const statusCode = 308;
addEventListener("fetch", event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
const url = new URL(request.url);
const { pathname, search } = url;
const destinationURL = base + pathname + search;
return Response.redirect(destinationURL, statusCode);
}
First, note that the redactions you are seeing are purely for display in the workers console. This is a feature to protect sensitive secrets from being logged, but it doesn't affect the content of any live request.
Now, with regard to what your Worker is actually doing:
This worker returns a 308 redirect response back to the client. It is then up to the client to follow the redirect, sending the same request to the new URL.
It is the client, then, that decides whether to send the Authorization header to the new location -- the behavior is NOT controlled by Cloudflare Workers. As it turns out, many clients intentionally drop the Authorization header when following redirects to a different domain name. For example, the Go HTTP client library does this, and node-fetch recently started doing this as well. (I happen to disagree with this change, for reasons I explained in a comment.)
If the client is a web browser, then the behavior is complicated. If the Authorization header was added to the request as part of HTTP basic auth (i.e. the user was prompted by the browser for a username and password), then the header will be removed when following the redirect. However, if the Authorization header was provided by client-side JavaScript code when it called fetch(), then the header will be kept through the redirect.
Probably the best way to solve this is: Don't use a 3xx redirect. Instead, have the Worker directly forward the request to the new URL. That is, instead of this:
return Response.redirect(destinationURL, statusCode);
Try this:
return fetch(destinationURL, request);
With this code, the client will not receive a redirect. Instead, the Worker will directly forward the request to the new URL, and then forward the response back to the client. The Worker acts as a middleman proxy in this case. From the client's point of view, no forwarding took place, the original URL simply handled the request.
I have trouble using cy.intercept testing API that not actually exist (after mocking data)
what I mean?
I have url like: .../users/hello.
cy.intercept("POST", "/users/hello", { fixture: "test.json" }).as(
"getTestUser"
);
hello value (in the url) came from mock data (from previous response) which means that it is not actually exist in the DB / server does not know this value.
the final result: I am getting 404 from the server (it not really know this value and throw authentication error )
how can I resolve it? can I intercept a dummy url and set the server side to ignore this url and then return my stub?
tnx
Your intercept is stubbing because you have specified a fixture. The request will never go to the server.
Take a look at the routes at the top of the test
When you specify a fixture, you will not get 404 from the server. The request will never get to the server (assuming you have specified the URL correctly on the intercept).
If you are getting a response from the server, it means the URL in the intercept is not matching correctly.
Take a look at the dev console network tab, check the full URL you are trying to catch.
Perhaps you just need a wildcard in front,
cy.intercept("POST", "**/users/hello", { fixture: "test.json" })
.as("getTestUser")
I just wanted to know whether is there any way block to HTTP requests made by POSTMAN? Just like browser with the help of CORS allows only specific origins to access a resource. Thanks in advance.
No.
In CORS, it's browser job to block request (or answer), your server does not know "truth" about request. If some power user will disable "following CORS rules" in browser settings/flags - your CORS settings will be ignored.
And even if you will find some "special headers" that POSTMAN will "understand" and refuse to work - there are many other "clients" that can send http(s) requests to server (curl, Fiddler, ...).
I am not aware of anything that gives away the fact that the request is made via Postman.
At the end of the day, Postman is a simple client so the fact that the request is coming through it, or any other client as a matter of fact is irrelevant. Postman's job is to help talk to APIs and even automate this process.
If you are worried about security then secure your API first. Then you wouldn't really care how you get a request, as long as it's authenticated and actually allowed to talk to your API.
This is maybe old for this question but one of the easiest way to handle such situation is to
app.Use(async (context, next) =>
{
if (context.Request.Headers["Referer"].ToString() != "http://localhost:4200/")
{
byte[] data = Encoding.ASCII.GetBytes("Not Recognized Request");
await context.Response.Body.WriteAsync(data);
return;
}
await next();
});
This is useful for .Net core and must set in startup--> configure section.
via this approach you will restrict your API to "Http://localhost:4200" which would be the "Referer" that you want to restrict to.
So because postman has no "Referer" it will get "Not Recognized request" as response.
I'm developing a new module in Chromium solution, in which I want to create and send a request to specific server. I've tried to implement this in many way: call Send() method of URL request directly, use URL fetcher, send via IPC route... but no one could be successful.