I'm brand new to Express Gateway and I'm trying to set up a basic API Gateway to link up some micro services. When I try and proxy to a specific end point https://my-service.net/status (not the real URL), I get this error
[EG:policy] warn: unable to verify the first certificate
I can access the URL 'https://my-service.net/status' in the browser just fine.
When I switch out the serviceEndPoint URL it works fine (e.g. to https://httpbin.org), so it seems like there's something different with my URL in terms of the SSL/authentication config.
Any ideas? Many thanks.
My gateway.config.yml -->
So the SSL setup allows me to access the page from a browser (Chrome), but at the command line (e.g. through my Express Gateway which is served by NPM and running locally on port 8080) it fails.
Related
I have a project which I have dockerised here: https://github.com/redis-projects/redis-movies/tree/gitpod
I am in the process of trying to get it to work correctly on GitPod, however I am having issues with the frontend react app hitting the backend java service. The react app is running in my local browser so I am confused by which network settings I should use and how to correctly configure.
The docker-compose file when used locally can simply use localhost:8080 to interact with the backend services, but GitPod generates a unique domain over HTTPS. Currently this causes the issues:
Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint '<URL>'. This request has been blocked; the content must be served over HTTPS.
This is self-explanatory, I cant make HTTP requests when the site is loaded via HTTPS. & even if I could, its pointing # localhost so the service wont resolve.
How can I setup my docker-compose + gitpod configuration to correctly configure the React URL
Currently use env vars:
REACT_APP_MOVIE_SERVICE_HOST=localhost
REACT_APP_MOVIE_SERVICE_PORT=8080
and this simply builds a url like so (apiConfig.js): http://${process.env.REACT_APP_MOVIE_SERVICE_HOST}:${process.env.REACT_APP_MOVIE_SERVICE_PORT}
Assuming that the backend services are exposed via a public endpoint, I will need to handle any CORs issues since these services are no longer 'local'?
I'm attempting to use Keycloak for some future projects and it's still very new to me so I'm plugging away reading through the docs and searching for issues online but I'm currently stumped on one thing - I have a vuejs app I’ve added as a client (127.0.0.1:3001), I have a reverse proxy setup in IIS (idp.mc.local) and then a docker container on Windows with keycloak running (127.0.0.1:8080), when I attempt to login, instead of being redirected back to the vuejs client I am just getting redirected to the root of the reverse proxy with the state value in the url, as in the network logs in the screenshot below:
Network logs showing incorrected 'Location' redirect
If I don’t set a front end url for the realm and bypass the proxy / hook my vuejs client to login via Keycloak directly on 127.0.0.1:8080, it redirects to 127.0.0.1:3001/#state… correctly, as below:
Network logs showing correct 'Location' redirect
I can't spot any way to sort this issue, I thought the front end url for the realm should state the proxy address? I can't see why Keycloak would redirect to it at the end of the login process rather than to my client app url, the redirect_uri is being ignored by keycloak and for some reason taking me back to the root of my proxy domain. If I actually manually visit 127.0.0.1:3001/#state… with the state value copied in from the incorrect redirect, I log in successfully.
It's baffling me and any help would be appreciated!
The answer did turn out to be an IIS related issue with the setup of Application Request Routing / ARR being the problem. What was needed was to edit the settings for IIS Application Request Routing and uncheck the option:
Reverse rewrite host in response headers as can be seen in the image below:
IIS ARR Checkbox to untick
Hopefully this will be helpful for someone else who might have the same issue at some point!
I'm integrating Azure AD into a server side blazor application. It works locally (using https), however when I deploy it to production, the redirect URI in the URL is HTTP, not HTTPS, which then once I log in, Microsoft say the redirect URI isn't valid.
I'm running a VM using Ubuntu and Apache, which is forwarding anything from port 80 to port 443 using a Lets Encrypt certificate, however when it sends the user to Microsoft to login, the redirect URI is http://mydomain.tld, rather than https://mydomain.tld. I think it's because the URL it's running on locally is http://localhost:9000 - But when I put it to https://localhost:9000, it throws an exception on start up as it doesn't have a certificate and as I'm not running on a development machine, I don't really want to install the net core SDK and create dev certificate.
I've seen a few people put this in their code to solve it, however my requests are still going through to Azure AD with a HTTP redirect URI:
var fordwardedHeaderOptions = new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
};
fordwardedHeaderOptions.KnownNetworks.Clear();
fordwardedHeaderOptions.KnownProxies.Clear();
app.UseForwardedHeaders(fordwardedHeaderOptions);
Any ideas on how to fix it? I can't imagine I'm the first to be using Blazor behind Apache and connecting via openid.
Two options:
1.Set up Redirect URIs: http://localhost/****
2.Edit the Manifest like below:
I created a custom domain mapping for my Cloud Run service following this guide https://cloud.google.com/run/docs/mapping-custom-domains.
I can access my service via the https run.app URL and the custom domain via HTTP, but when I go to the custom domain via HTTPS, I get back a Google 404 error page.
The weird thing is, this seems to be an issue on my local laptop (both browser and curl on the terminal), but curl-ing it from a remote server seems to work ok.
As #LundinCast pointed out, there seems to be an outage on the Google server side. I'll monitor the situation and mark this as resolved for now.
Edit: I'm guessing this is related to https://status.cloud.google.com/incident/cloud-networking/19016
Using Angular-CLI as a frontend. 4200 port
Using Express as a backend. 8080 port
Directories look like:
Application
- backend
- ...Express architecture
- frontend
-...Angular2 architecture
So I'm running two projects, two commanders, one for frontent, second one for backend. node app.js for backend (8080), ng serve for frontent (4200).
Let's assume that I have a layer in backend which returns some string.
app.get('/hello', function(req, res) {
res.send("Hello!");
}
How can I make a request from frontend to backend and get that string? I don't want to know how exactly should I use Angular2 because that's not the point. I'm asking, what technology should I use to be able connect these two (frontent and backend) sides on different ports. If I just run them and make a request from frontend, I'll get an error because it can't find /hello url.
Your request to /hello means an absolute path inside the application running the angular application, so the request goes to http://localhost:4200/hello. Your angular application just doesn't know about the express application you want to target.
absolute urls
If you want to access the hello route on the other (express) application, you need to explicitly specify this by referencing http://localhost:8080/hello.
cors
Doing it this way, the correct application is targeted, but you will likely run into CORS issues, because the browser will prevent the javascript code obtained from localhost:4200 to access a server at localhost:8080. This is a security feature of your browser. So if you want to allow the code at 4200 to access the backend at 8080 your backend can whitelist this so called origin. For details see http://enable-cors.org/ and a corresponding express middleware you could use to support cors in your backend (https://www.npmjs.com/package/cors).
Using this approach has two downsides in my opinion. First, you need a way to tell your frontend under which absolute url it can reach the backend. This must be configurable because you need different urls for dev, staging and production. You then also need a way to manage all your whitelisted urls because the frontend in production will have a different url than when running the frontend in development. This can get pretty cumbersome to handle.
proxying your backend
A better approach in my opinion is to handle this in your infrastructure by proxying the backend in your frontend application. With proxying you basically tell your frontend server that all requests to some url should be passed through to another application. In your case this could probably mean, that for example you configure a proxy for the path /api/ to proxy the application on localhost:8080. The server then doesn't try to find a url like /api/hello on your frontend application but forwards your request to localhost:8080/hello. In your angular application you then don't need to care about the url of your backend and you can then always do a request to a url like /api/some-express-route.
For this to work you need to configure your angular dev server to proxy the requests. For details on how to do this, please see the docs at https://angular.io/guide/build#proxying-to-a-backend-server. When going to production, you can do this by configuring your web server, e.g. nginx to proxy the requests.