Swagger UI - TypeError: Failed to fetch - on endpoint request (ASPNET Core API) - asp.net

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

Related

How to call http://metadata.ggogle.internal from within web app loaded over https

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.

Cross domain (CORS) error in asp.net / Angular server

I am working on Angular 1 / ASP.net tech stack based web application.
For some reason, I can not deploy api server on my local env, using Production server. And I launched UI side with nginx in local env.
Login page is:
http://localhost:8080/login.html
And when click login button, it calls API from production server.
http://devprod2.com/api/oauth/login
But I am getting error:
Response for preflight has invalid HTTP status code 400
I opened Cross domain option in browser, with chrome CORS extension.
But it seems this error is related with some CORS problem.
Would you like to help me to fix this problem?
A preflight request occurs when you use certain methods, e.g. POST
It is a request that automatically happens before the cross domain POST happens.
It is checking to see that the correct CORS headers are in place on the server before making the POST request.
It seems like your preflight OPTIONS request is giving an invalid response. On your server, make sure you return 200 for all OPTIONS requests and make sure the CORS headers are in place on the server for all requests.
I believe Angular 1 also has options for a POST request that will prevent preflight requests from being made but you would have to investigate this further yourself.
Alternatively, depending on your setup, it maybe possible to rewrite the request to avoid CORS which is only enforced by browsers.

Wordpress Ninja Forms, Access-Control-Allow-Origin and admin-ajax.php

So, I have this WP installed on Heroku and I've installed Ninja forms to it. Despite everything working OK locally, when I push it to Heroku, the form is not submited and I receive this error through the Chrome's Console:
Failed to load https://ratts.com.br/wp-admin/admin-ajax.php: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://ratts.com.br' is therefore not allowed
access. The response had HTTP status code 503.
It's worthy to mention that this error is only delivered when I access the page via http, but when I access the page trough https the form works just fine, due to what I think to be a CORS problem. Anyone has any idea about how can I solve this issue? It have been three days of unsuccessful research already... rsrs
I believe that http to https for the same domain is still considered CORS. You need to make sure all traffic is redirected from http to https. Take a look at this thread.

When service through external host name returns wsdl html instead of the expected response envelope

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.

IIS7 HTTP to HTTPS redirect makes asp.net API fail with "document not in recognised format" "Client proxy code is empty!"

We publish an asp.net API on:
http://API.domain.com/v3/service.svc
https://API.domain.com/v3/service.svc
Had a problem last week with a corrupt SSL certificate which meant connecting to the HTTPS ref fails with an internet explorer connection problem. HTTP ref was fine, was confirmed the SSL corruption was the issue.
A customer that should have been using HTTPS never noticed, logs confirmed they are actually using HTTP for authentication and data.
When testing with WCF STORM (test app I used to test method calls) I could recreate the issue i.e HTTP ok & HTTPS fails. Installing a backup certificate resolved the problem instantly, everything back to normal operation.
So I started looking at HTTP to HTTPS redirects. Got it up and running using http://www.iis-aid.com/articles/how_to_guides/redirect_http_to_https_iis_7 (i.e the change to web.config).
When browsing to my API HTTP and HTTPS url, everything worked as expected.
When using WCF STORM to I get the message:
System.InvalidOperationException: The document at the url http://API.domain.com/v3/service.svc was not recognized as a known document type.
The error message from each known type may help you fix the problem:
- Report from 'DISCO Document' is 'Discovery document at the URL http://API.domain.com/v3/service.svc?disco&disco could not be found.'.
- The document format is not recognized.
- Report from 'http://API.domain.com/v3/service.svc' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
at System.Web.Services.Discovery.DiscoveryClientProtocol.DiscoverAny(String url)
at WcfStorm.DynamicProxy.ServiceClientProxyFactory.(Option`1 )
at WcfStorm.DynamicProxy.ServiceClientProxyFactory.DiscoverEndpoint(Option`1 cfgOption)
at WcfStorm.Model.WcfServiceModel.(ServiceClientProxyFactory )
at WcfStorm.Lib.Common.BgWorker`2.OnDoWork(DoWorkEventArgs e)
Client proxy code is empty!
I remember one of the developers telling me that the AUTHENTICATION uses SSL but the SOAP messages are transmitted over HTTP. Therefore I suspect the HTTP to HTTPS redirection has caused this issue as its forcing the SOAP messages to use HTTPS and the API has not been configured to do this .... I'm guessing? Developer explained that its recommended that APIs using HTTP for transmitting the SOAP data after authentication using SSL to confirm credentials.
Questions:
How do we force the SOAP data to be transmitted over HTTPS if this is deemed the solution?
If this is not possible how do i deployed HTTP to HTTPS redirect within the environment above ?
Any other way to force HTTPS onto end users / disabled HTTP and / or redirect to HTTPS ?
Thank you for any help.

Resources