Dotnet core 3.1 blazorwasm template app is giving the below error while accessing from network or after hosting it on a linux server. It seems the published app is always looking for local host ip for redirection at certain places.
the errors appeared on the firefox console is given bellow
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:5000/.well-known/openid-configuration. (Reason: CORS request did not succeed).
how to configure and publish it to avoid routing to localhost.
This can be reproduced by simply taking the code
https://github.com/dotnet-presentations/blazor-workshop
after running it from visual studio try to access it from a remote client (another machine) will give error while navigating from login and registration links.
Try adding the following CORS middleware configuration to the web API's service's Startup.Configure method and see if that works:
app.UseCors(policy => policy.WithOrigins("http://localhost:5000", "https://localhost:5001")
.AllowAnyMethod()
.WithHeaders(HeaderNames.ContentType));
You need to add this to this file if you are using the code mentioned in your question.
Doc and sample project can be found here.
Related
I have an ASP.NET API running locally. On the MacBook Pro, I can access the endpoints with Swagger, Postman and in the frontend (running on LiveServer) using Axios/JavaScript.
I have successfully loaded the frontend webpage on an iPhone (192.168.0.10:5500/index.html), however the Axios call to the endpoint is failing with the following error message logged to the console Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “192.168.0.10”, which could put your confidential information at risk.
Running the command dotnet dev-certs https --trust generates the message Successfully trusted the existing HTTPS certificate. but does not resolve the issue.
Am I missing something?
#Lex Li's comment worked.
Steps
Remove or comment out app.UseHttpsRedirection(); in program.cs file.
In the launchSettings.json file, "applicationUrl": "https://localhost:7139;http://localhost:5171", generates a http and https url for the API endpoints. Edit the http route to the IP of the computer/local server, e.g., "applicationUrl": "https://localhost:7139;http://192.168.0.10:5171"
use the http endpoint
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've got a Meteor app that has been working fine. When deploying to iOS or Android, it still works fine.
But, when deploying to localhost, I now suddenly encounter this console error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at {{external json resource}}. (Reason: CORS
header ‘Access-Control-Allow-Origin’ does not match
‘http://localhost:12616’).
What I find eyebrow-raising is that my app, when running on localhost, runs on port 3000.
The app picks up external data from a Wordpress installation, using the Wordpress API. In that Wordpress installation I've got the following:
function add_cors_http_header(){
header("Access-Control-Allow-Origin: *");
}
add_action('init','add_cors_http_header');
How to resolve this?
I'm on Meteor 1.8.1.
So I have taken the heroes tutorial from Angular 2, used it with an angular-cli project. Running ng serve and using in memory api, it works.
Changed the server url to point to my tomcat server that is providing a rest api. I have tested this with curl and it gives back data.
I then built it for production and put the resulting bundles into nginx on the same machine as tomcat.
Run in Firefox, get correct page but no data. Console shows the GET is OK. But I do get
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://centos7:8080/heroes/heroes. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
Other questions in StackOverFlow on this topic say that both must be in the same domain, which they are, the tomcat server is centos7:8080/heroes/heroes and the nginx server is centos7/
Should I have to open up CORS? I have seen http://enable-cors.org/server_nginx.html so I need to add this in nginx.conf?
Does anyone have any ideas?
Regards
So I am not if this is the abolute answer but it removed the CORS error in browser console.
In my grails 3 rest api application, I added the grails 3 COR interceptor https://github.com/appcela/grails3-cors-interceptor.
I now get a different problem but I will raise that in a separate question.
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.