I have an Angular web app running on Cloud Run (nginx webserver) (more info here) from which I want to get access token from the GCP metadata server. I have tried to make a call to https://metadata.google.internal ( using curl from Cloud Shell) but the connection was rejected. Calls to HTTP are working well.
When I make the call from my app (which is loaded over https) to the metadata server over HTTP - logically I get a mixed content error. When trying to access the metadata server over HTTPS - I am getting error 504 Gateway timeout, I assume due to the reason that the metadata server refuses the calls on HTTPS.
I will really appreciate any idea of how to solve this issue.
The URL endpoint metadata.google.internal is only accessible from inside the instance (Cloud Run). This endpoint is not accessible outside of the instance such as via an HTTP or HTTPS call. A clue is the TLD (Top Level Domain) internal.
If you want to access this endpoint remotely via a web browser, you will need to make a request from the browser to Cloud Run (an endpoint in your code) which then makes the internal request to the metadata server and returns the response to the client.
Related
When trying to run a request through swagger UI, I receive the following response on Swagger
TypeError: Failed to fetch
After searching around, I found that a possible cause of this error is because of a CORS issue, where the origin is changed in the request (as you can see at this other post here). However, in my case, this is not running through some other proxy, it is hosted on a locally hosted server and that server is not changing any of the headers. I realized this when I tried to allow the API to just accept any CORS headers to test if this was the issue; sadly it was not and the issue persisted.
The API is running on IIS hosted on a server that is hosted locally. The API is running as an application on the default website and is accessed via the following url:
http://servername/application-name/swagger/index.html
Can anyone help with this issue?
After further investigation, I found that when I looked at the requests being sent to the server through the dev tools on the browser, that the URL was being changed from http to https on the request of the endpoint through swagger.
HTTPS, has not been set up on the server and returns a 404 (as seen in the dev tools).
It turns out, that even though the server has not been setup to serve content via HTTPS, the requests where still redirected to HTTPS and this was the reason
app.UseHttpsRedirection();
So, even though swagger was able to be loaded on HTTP, when the request was made to the API, the API responded with a 307 - for redirection and the request was redirected to HTTPS - which in turn returned 404. This 404 response was the cause the TypeError: Failed to fetch
The recommended fix for this is to turn off https redirection (ONLY FOR TESTING PURPOSES) and the other is to enable the server to serve the content correctly over HTTPS, so that when a call is made, it is not redirected, but rather sent straight to the correct API address on HTTPS - which should not return the data correctly, since the server can serve HTTPS content
I am using Sustainsys.Saml2 for authentication in my environment. It has worked well until I added a proxy into the loop.
The data flow is:
1) User navigates to site via proxy server (example.mysite.com)
2) Proxy forwards to internal application (example.internal.mysite.com)
3) Saml does its thing, forwards to service for authenticate and redirect
step
4) Weird part: The saml response is sent back to the original host hitting Saml2/Acs (example.mysite.com/Saml2/Acs) and responding as a 303 -- the assumption is that it should be 303'ing to example.mysite.com, but instead it's to the proxy host name at example.internal.mysite.com
Why is it doing that? It doesn't seem to be respecting the ReturnUrl (which is example.mysite.com). I see no evidence of the proxy URL from requests/responses during the auth process until #4.
The Sustainsys.Saml2 library builds various URLs from what it sees in the incoming HTTP Request. When a proxy is involved, that might not be the same URL as the client sees.
There's a setting PublicOrigin that you can set to handle this, that will override any host found in the request.
However, in The AspNetCore2 handler it is assumed that this has already been fixed in the Request object, before the handler is invoked. This is usually done automatically by the hosting environment if hosting in Kestrel behind IIS or similar.
I have an IIS-hosted, WCF web service deployed on a UAT web server. In IIS, I have site bindings on this same web service--one for internal access (Ex: uat-nodotsinternalonly) and one for external access (Ex: mysvc.uat.mydomain.com).
When I use SoapUI to test against the internal host name (http://uat-nodotsinternalonly/MyService.svc), it calls the service and returns the response envelope as expected.
When I use SoapUI to test against the external host name (https://mysvc.uat.mydomain.com/MyService.svc), it calls the service and returns the WSDL HTML as would be seen in the web browser instead of the response envelope as expected.
We need to expose past our firewall for testing with a vendor. Our external client can browse to our web service using the external host name and receive the WSDL back in their web browser, but when they call it, it fails with a 302 error.
I’m far from an expert on security, but I believe our firewall is handling the security then forwarding over http to the UAT server. The redirect and variations seem as though there’s something to change in how DNS is managed or settings in IIS. Does anyone have suggestions as to how to narrow it down so that the call to the external service will work?
We too had a WCF service that in SoapUI was returning the WSDL HTML instead of the expected response when invoking a method. This was an SSL-enabled service, and the solution in our case was to edit the endpoint URL after creating the request so that it used https instead of http. This is because we found that for some reason it defaults to http even when you initially specify https when creating the request. Here's how to edit the endpoint URL in SoapUI:
In the request window, click the drop-down arrow on the URL.
Select [edit current..]
Change http to https, and then try your request again.
The problem with the client getting a 302 error was because the client was not sending a SOAP request envelope to our web service. The client was just sending XML.
I have an apigee proxy that routes request to backend services - which is a standard usecase. In the dev environment the backend is lenient in terms of headers/query params. However this is not the same in the production environment - the backend server operates in strict mode.
I would like to validate the request sent to the backend - probably using JMeter in dev mode so that the proxy does not fail in production. Any ideas on how to do this?
One of the ways is to copy the request sent to backend on to the response and validate final response in JMeter. This may not work in all cases.
I would like to know vairous ideas that people have tried to test in such a scenario.
Please assume that the dev backend cannot be made strict due to variety of circumstances.
One possibility is to add an HTTP header indicating that you are in testing mode. Then use RouteRules in the ProxyEndpoint to send the request to a testing endpoint instead of your normal backend if that header was supplied. That testing endpoint could receive and validate your request. You could also do this with an optional service callout before the normal call to the backend.
Following is our environment setup:
IIS 7 receives Http (.jsp) request from client (browser).
It blindly redirects it to JBoss using ISAPI_Redirect.dll.
Now we are trying to modify this setup in such a way that before IIS7/ISAPI_redirect sends it to JBoss, we need to modify posted form data using Http module. This http module is normal .net http module.
We are able to intercept the request # BeginRequest event of http module and when we send it to JBoss, it gives us "Read client failed (400)" error.
Any idea how to achieve this task or fix the problem at hand?
We were not able to fix our problem in its original form. What we did is we removed ISAPI_REDIRECT/JBoss from our original pipeline.
We now take the request directly to our http module by setting up another virtual directory where ISAPI_Redirect is not configured, we do our modification (earlier we intended to do this after JBoss has received the request) and then send it to another virtual directory (URL) where ISAPI_REDIRECT is configured. Now ISAPI_Redirect captures the request, maps it to JBoss format and sends it to JBoss.
Basically we switched the place of our customer processing and things seem to falling in place.