Cypress E2E fails on basic auth - javascript

I'm trying to use cypress to cover our dev-server by a set of complete e2e tests.
We have a requirement to lock our dev environment under basic http authentication so nobody couldn't access it without proper credentials (both client and api).
When I'm trying to run Cypress tests they fail because of that. Server (nginx) just responds with 401 http-code.
I tried to pass credentials in url like 'user:password#domain.com', and it partially works: cypress is able to reach frontend on domain.com, but it's still unable to send any requests to our backend (api.domain.com) from within the page (using fetch) - probably because of different subdomain or something.
I'm looking for a way for forcing it to use those credentials on all requests on a domain or any other workaround that may help me run the tests.
Thanks!

This might not be an auth issue. fetch does not work with cypress. See https://github.com/cypress-io/cypress/issues/687
A workaround for it is to put this into your support/index.js file:
Cypress.on("window:before:load", win => {
win.fetch = null;
});

Related

How do I send my stripe webhook to my Heroku app?

I've integrated Stripe into my javascript app which works fine in my test environment using ngrok but once I switch to prod, my app is timing out as users attempt to leave the Stripe checkout screen.
The Stripe webhook kicks error Timed out connecting to remote host and I think it's because I have the wrong endpoint.
Testing endpoint
https://6752-136-62-45-90.ngrok.io/users/stripe/webhook
Live endpoint
https://myapp.com/users/stripe/webhook
Everything else in the integration appears to work -- the customer is still created and the billing goes through but I need the endpoint code to run because it builds some critical infrastructure in the user profile.
I also have SSL encryption setup and DNS target on my Heroku application so I'm wondering if I should be using the DNS target or the Heroku app name for the endpoint instead of my domain.
My question
I can't really find any documentation on this but how do I configure my Stripe endpoint with my Heroku-hosted app?
You can test by setting the Heroku app name directly to check if it works to narrow down the issue. If it still doesn't, then most likely it's due to network issue.
Timed out connecting to remote host usually means that the server is not responding. This is likely due to network configuration such as firewall blocking the Stripe IP addresses. I'd recommend checking your network configuration and ensure that Stripe domains/IP addresses are in the allowed list: https://stripe.com/docs/ips

Cypress: Add cookie to external api calls from localhost frontend

I have an external api deployed to a dev server and a frontend app running on localhost. I need to attach the cookies I get from logging in, to both my localhost and external API domain.
I can see the cookies are indeed there using cy.getCookies({domain: null}), however all external API calls within the react app happen without the cookies. From what I can see, you can only add cookies to the baseUrl requests, but I want to run my tests against a deployed backend (so developers don't need to have a running instance of a local backend, which is whats currently working fine as they are both on localhost)
cy.setCookies(name, value, {domain: localhost})
cy.setCookies(name, value, {domain: external_api_domain})
If there is a request originating from the app to the back-end that needs a specific cookie attached, maybe an intercept can attach them.
This is untested & on-the-fly code, may need adjusting
cy.intercept('POST', my-url, (req) =>
const cookie = cy.getCookies(name).then((cookie) => {
req.headers['Cookie'] = `${cookie.name}=${cookie.value}`;
req.continue()
})
})
Assumptions
I'm assuming the frontend initiates the request that the backend then passes on to another server, and backend gets all info (including cookies) from the frontend request.
Debugging
You can check the backend phase is working with cy.request(). Ultimately you want FE to do it, but in case the problem lie in the FE and not the test cy.request() can be useful.
For ref Cypress request and cookies

Apollo Explorer Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID

I am running an Apollo Server with express to create an http server:
const express = require("express");
const cors = require('cors');
const app = express();
const server = new ApolloServer({ ... });
server.applyMiddleware({ app });
// enable pre-flight for cors requests
app.options('*', cors());
// Create the HTTP server
let httpServer = http.createServer(app);
httpServer.listen({ port: config.port });
Locally I can run the server and query it on Apollo Explorer without any issues.
However, when I deploy this server on dev environment, and try to access the Explorer page with the dev endpoint, I get a few errors.
The app.options() line with cors argument somehow seems to have solved part of them but not all.
Errors I am getting (on Dev Tools console):
Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID
POST https://dev.endpoint.service/graphql net::ERR_CERT_AUTHORITY_INVALID
Errors I am getting (as popups on the Explorer page):
Unable to reach server
To diagnose the problem, please run:
npx diagnose-endpoint#1.0.12 --endpoint=https://dev.endpoint.service/graphql
I've tried running the command as instructed in the error and got this result:
Diagnosing https://dev.endpoint.service/graphql
Could not find any problems with the endpoint. Would you please to let us know about this > at explorer-feedback#apollographql.com
Frankly, I'm not even sure I understand the problem.
Am I getting these errors because, even though I launch an http server of Apollo without certificates, I am trying to access it via an https endpoint (which requires certificates)? I have to do this, service is stored in AKS cluster, which is only accessible through the endpoint I am calling. But every service that is already there is also an http service, not https, and is accessible through this same endpoint.
Also, even though these errors are showing up frequently, I am also able to query the server successfully most of the time on Explorer, and the data returned is exactly what I expected, which makes even less sense.
I am using edge browser but also tried chrome, and have the same issues.
How can an error like this be intermittent?
Without any intervention on my part, sometimes it's like this:
Any help, hints, ideas, please.
Thank you so much.
As much as it pains me to admit, it seems the issue is related to the VPN my company is using.
There were a few tells that pointed in this direction, once I started paying attention:
We can't access the endpoint I mentioned without the VPN turned on.
Other services in the AKS behave with the same error, if being called constantly through the same endpoint. I did not think to do that test at first, but when I realized that on Apollo server, the server is constantly doing the introspection thing to check the schema, it means it is being called more often than the other services that do not have this functionality.
We have some monitoring tools, to check the pod statuses and so on, and nothing indicated any problems in this service, or that it needed any kind of pod escalation (due to excessive number of requests).
I actually performed kubectl portforward test linking my localhost directly to the AKS cluster. Calling the service this way bypasses that endpoint which I am, under normal circumstances, forced to use before the request actually reaches the cluster. And I was simultaneously seeing on one window where I was calling the service the normal way showing that error on Apollo Studio, and at the same time on another Apollo Studio window performing the same request with this portforward bypass mechanic, and the latter was working just fine. If it really was a problem with the service, it would be down for both windows.
Other colleagues were testing the service at the same time as me and they were saying the service was working fine for them, until it wasn't. So every developer on my team could be accessing the service at the same time, and the error would just randomly show up for some, but not for others.
There are long periods where the error doesn't occur at all, like during lunch hours, or after work hours, and I assume the VPN traffic will be much lower during those hours.

Server side mocking of node using testcafe

my use case is to explore how could a server-side requests be mocked. I am successful in mocking client side request using requesthooks but with server side testcafe is not able to intercept the request.
Frontend is built using next.js, and at intial page load, getinitalprops prepares the page by using fetch (get request) which happens at server side(node) not browser, and testcafe is not able to intercept.
I want to introduce testcafe in my team for frontend dev & their requirement is to resolve their pain of mocking server side requests before they start using testcafe for integration testing. Please suggest if this is possible with testcafe.
TestCafe works in a browser and does not know a lot about your server-side logic, so TestCafe can intercept only the requests sent from your browser. In your specific case, probably you need to modify your project by integrating some request mocking framework into your server app.

Fetch request to localhost with basic auth

Is it possible for a webpage, like https://example.com perform an http request to localhost?
This is an uncommon situation. Let me explain:
My visitors have a local server running. They can access their server in a request to http://localhost:12039/wallet, which returns a json.
When the visitor opens my page (at example.com) could the JS in that page perform a request to their local server?
To make it even more complicated: the server don't add CORS header and the it also required an Basic Auth.
From postman, everything work as expected. But not from the browser (if not called from localhost)
I did some tests, but it's not working yet.
I'm not able to send the Authorization. When I run this code, there's a prompt from the browser, asking for username and password:
It's really hard to Google this terms. Most of the results are related to localhost calls for your own api during the development.

Categories

Resources