node stripe deployment issue - node.js

I made a react add with node backend using the stripe express checkout form, and passing the source and other data to the backend to subscribe users, but on production it does not work.
I have it on an ubunutu vps, and the app is served with nginx as a reverse proxy of localhost. but it is not working, i also added ssl certificate to the domain but I am getting an error now that says:
Blocked loading mixed active content “http://localhost:8080/api”
on the server version in stripe test mode.
how can this be fixed?

In production it is required that you use SSL with Stripe. Your error is because you are trying to load or access http://localhost:8080/api from an originally https page. Stripe requires that all of your resources are loaded via https/SSL.
You also probably shouldn't be loading localhost in production. You should be using your actual hostname in production with https.
Let's say you load https://example.com/ in your browser. And you want to make a call to your backend server that is running on https://example.com/api. Instead of specifying localhost you can just change the URL to be /api and that will automatically append the domain name https://example.com to the request. This only works for the same domains. If it's separate domains you have to specify the domain name in your request.

Related

Setting up a gateway with express-openid-connect

I have an express server running on api.domain.com. I'm using express-openid-connect to handle the authentication flow. This server also acts as a proxy to other downstream service that require authentication.
----------- ------------------ ----------------------
| Clients | ---> | Express server | ---> | Downstream service |
----------- ------------------ ----------------------
There are potentially multiple client applications calling the express server, all running on different sub domains (client1.domain.com, client2.domain.com, ...).
The idea is that whenever a client needs to call a service, the request would go through the gateway first, the gateway would add the Authorization header to the request, then proxy it to the right service.
The problem I have right now is that the cookie created by express-openid-connect is for the domain api.domain.com. I know I could change the domain the cookie is set to to domain.com, but I'm looking for a solution that would also work if one of the client is running on localhost (during local development). Is there any way that I could achieve something like this?
You can create a subdomain for local development and use a DNS solution to resolve it locally. The simplest option is often to just update your conputer's hosts file with a made up subdomain:
127.0.0.1 client1-local.domain.com
Then browse to a URL such as this during development. This will keep the cookie first-party if the HTTP scheme is the same as the remote API (ports can be different). If you use localhost the cookie will be considered third-party and browsers will not send it.
http://client1-local.domain.com:3000

Azure Frontdoor: Requests go to invididual backends, why?

I have set up an Azure Frontdoor Load Balancer with 2 backends, hosting an Angular app. When looking at the network traffic in the browser's developer tools, I see that only the first few requests for *.html and *.js files go to the loadbalancer. Beginning with the GET options request, all subsequent requests seem to go directly to the backend #2 (in red in the picture below):
This means, if the backend #2 goes down, the client gets 404 errors, and won't be automatically redirected to backend #1, unless the user reloads the browser window with F5.
I'm not sure how the Angular app gets the actual backend host's URL. I cannot see any header or cookie which would provide this information. The headers of the first request for login.html look like this - no sign of the backend URL anywhere:
My questions are
how does the client get the backend host's URL?
is there a way to define that ALL requests go through the loadbalancer?
Would that even be a good idea? Or is this the "intended behaviour", meaning that the user WILL see 404 errors and have to reload the page manually?
It the application that is doing it, not the azure front door. The app must be constructing the url based on where it is hosted and them making a request. The front door will set the host header same as the app service's hostname. In that case, the application would see it's request to come as if the user typed that in the browser. You would typically want to use custom hostname e.g. neonapp-dev.yourcompanyname.com. When you do that both app services and the front door would have the custom host configured. While configuring the front door, you would use this as a host header rather than the default which is app services host name. Then everything would work fine as the app would never see the app services name as host header.
More details https://learn.microsoft.com/en-us/azure/frontdoor/front-door-backend-pool#backend-host-header

Cloudflare SSL: Express Not Working After SSL Appli

Please consider my circumstance:
I have created a backend API on port 8880 in Express.js in HTTP
I have created a frontend website in Next.js on port 80, also in HTTP.
I signup with cloudflare they manage my DNS, I get their SSL so my frontend HTTP site becomes HTTPS.
After successfully applying SSL to the frontend, the backend api stops receiving the POST request from login from the frontend.
As a result, I can no longer login to my site because every attempt fails when the POST request attempts to send the JSON payload of the login. How can I fix this SSL brokenness? This worked perfectly fine as HTTP to HTTP. But now, as HTTPS to HTTP, got failure.
Here is what I have tried to solve:
HTTPS to HTTPS - this failed. I tried changing the backend to HTTPS but used a self-signed certificate following this instruction.
My code in app.js (backend):
https.createServer({
key: fs.readFileSync('server.key'),
cert: fs.readFileSync('server.cert')
}, app)
.listen(port, function () {
console.log(`Connected on port ${port}`)
})
Set up my Cloudflare Page Rules - Apparently cloudflare has "Page Rules" settings for your domain so I set mine to domainname.com/api SSL: Flexible. Still failed. Testing in Postman showed I was successfully signing in with https://123.456.789.10:8880/api/signin but not with https://domainname.com/api. I enabled morgan on Express and saw no ping on the /api/signin endpoint.
Switching the backend from HTTPS to HTTP, leaving Page Rules on SSL Flexible - As per this answered question here, I was thinking this will surely work since Cloudflare says "The Flexible SSL option allows a secure HTTPS connection between your visitor and Cloudflare, but forces Cloudflare to connect to your origin web server over unencrypted HTTP. An SSL certificate is not required on your origin web server and your visitors will still see the site as being HTTPS enabled." Doing this also failed.
And so, I am still unable to reach /api/signin either on domainname.com/api/signin or https://123.456.789.10:8880/api/signin or http://123.456.789.10:8880/api/signin. Morgan shows nothing in the console when I attempt signin, whereas it did before.
SOMEBODY out there must have solved setting up a frontend and backend on one IP but two different ports and gotten it to work with cloudflare SSL before. Please help!
I was able to solve this by implementing NGINX and setting the config to take / and /api and make them route to the respective apps running their port numbers. Additionally, I had to set up cors in my Express backend and used dotenv to allow a .env file to persist the FRONTEND_APP environment variable containing the ip address of the frontend Next.js app.

JsonServiceClient not including session cookies in API requests for subdomain - ServiceStack

Using the Typescript JsonServiceClient in an Angular app, the ss-pid cookie value keeps changing because JsonServiceClient is not including ss-pid, ss-id and ss-opt in requests to my APIs.
The subdomain I am using for my Angular app is app.serverfoo. The APIs reside at serverfoo:5001, serverfoo:5002.
The reason I am doing this is that I am working with my Angular app localhost and calling my 20+ APIs residing in development environment serverfoo, I ahve the following entry in my hosts file:
127.0.0.1 app.sdlxvh03
This allows my app to be run localhost, while I do development using ServiceStack sessions on my machine and still work with my APIs in the development environment.
Cookies only apply to the domain that the request was served from. See this previous answer on how to configure domain cookies so they can apply to sub domains as well.
https://stackoverflow.com/a/23631061/85785

SSL Certificate Not Working for my Azure App Service

I choose to host my website in Azure.So I've created a App Service.Then Created a new domain for my App then created/bind the SSL certificate to my corresponding website.
After done with the SSL certificate .I'm still seeing my website url as http//: and not https://
Also i'm not seeing the Green URL for my Website ..!
It look like this
(P.s : My App Service Tier is AzureFreeTier (Basic: 1 Small)
My SSL Type is SNL SSL)
Please help to resolve my problem here
Thanks in Advance,
Jayendran
You need to do a redirect from HTTP to HTTPS. Installing a certificate just makes using HTTPS with your custom domain name possible.
You can either:
Configure your app to redirect to HTTPS when it receives a request over HTTP + enable HTTP Strict Transport Security
Or use an extension in Web Apps to do the first thing:
To install the extension, open your web app blade in Azure Portal. Go to Extensions, then click Add. Then you should find Redirect HTTP to HTTPS from the list and install it.
That will redirect any HTTP calls to HTTPS for you. I would still recommend adding Strict-Transport-Security headers to your responses to make sure your clients do not access your site insecurely the next time.
The reason you arrive to your site on HTTPS after AAD login is because the HTTPS version of your app's URL has been configured in AAD as the reply URL.
And this:
Your Connection to this site is not fully secure Attackers might be able to see the images
is a mixed content warning. It means you are loading content (e.g. images) using an HTTP URL in your pages. Change them to HTTPS and you will solve that problem.

Resources