I'm currently creating an MVC 6 project (beta 8) which includes some APIs. Along with this is an accompanying Word App which talks to these APIs (just GET methods at present), however all my ajax get JSON requests from the Word app result in an 'Error: Access is denied.' message.
After much searching I believe this may be a CORS issue, so I have enabled this in my startup.cs by adding the following into ConfigureServices:
services.AddCors(options =>
{
options.AddPolicy("AllowAllOrigins", builder => builder.AllowAnyOrigin());
});
and then
app.UseCors("AllowAllOrigins");
into Configure, but this makes no difference, I still just receive the access denied message. I've attempted adjusting my CORS options to allow all methods and tried various other options, including adding
[EnableCors("AllowAllOrigins")]
on the actions, but again it makes no difference.
I am running both projects locally and manually navigating to the api via a browser returns the results without a problem, as does my swashbuckler setup.
Am I missing something obvious here?
In my experience, some browsers don't allow the wildcard response for allow origin when over an SSL connection (which is what you get when you use AllowAllOrigins). If you need your traffic to go over SSL, you need to respond with a list of allowed origins instead of the wildcard.
This answer has a good approach.
Related
Trying to provide more info and not sure how much is relevant.
One of our webapi is deployed to IIS : abcdomain.com/xyzweb. We started upgrading our env to .net 7 from .net 5. Web api also uses ServiceStack 6.4.
One of the route defined in the c# Webapi, ServiceStack plugin is "/api". Until recently requests to endpoint abcdomain.com/xyzweb/api was fine. But now (.net 7 upgrade?) we noticed that the calls to endpoint does not reach the (http get/post method) handler. We have a small middleware defined in startup.cs configure method and see the execution flow through the middleware code when the abcdomain.com/xyzweb/api request is made and the middleware ends by calling next() and after which execution flow lost (webapi is still live).
After much trials, something I read but could not put my fingers on the content, went ahead and changed the route definition to "/apihello" instead of "/api" and then the requests started working as before.
Any pointers what made it break or what made it work?
Searching is difficult with "api", brings only irrelevant results.
I would like to add that before changing /api to /apihello, the http request would return HTTP status 200 (though it did not go to the handler) and Raw response "Error: System.NotImplementedException: The operation '' does not exist for this service".
You can disable (or change) ServiceStack's JSON /api pre-defined route with:
ConfigurePlugin<PredefinedRoutesFeature>(feature => feature.JsonApiRoute = null);
I have a microservice in a non-prod environment which another team is using in another non-prod app that's handed off to 3rd party integrations for testing. That other team unfortunately presents users with the entire failed response of any API calls rather than logging it and returning something generic. Unfortunately, that means that they can see the Authorization header which includes "Bearer {tokenHere}".. This wouldn't normally be an issue in a development environment, but my hands are tied right now and I don't want to completely disable the exception page just because someone else is improperly leveraging that information.
I've looked at the options we have for configuring the developer exception page, but it's very limited. Is there anything I can do to remove the authorization header or all request headers if that's not possible?
note:
In an api call that returns json, this info. is displayed after the stack trace in a new section starting with "HEADERS"
When using ITHit WebDAV server it applies its own CORS settings, this is OK for the Verbs and Methods in my case. However it only allows on to configure one Origin, in my case I have multiple origins I need to support. So is it possible to make ITHit use the origin settings that is configured on an application level without it overwriting it?
I ended up creating my own middleware that adds/replaces the Access-Control-Allow-Origin header on the response after it has passed the ItHit middleware, with the Origin from the request if valid. If the request is invalid is still up in the air as there are multiple flavors on how to deal with it, for now i just send a 403 without processing the request.
I hope IT Hit will do an update to not roll their own implementation and use the native one part of Asp.Net Core.
I'm developing a web application based on an Angular 6 client and ASP.NET Core WebAPI for web services.
At the moment (initial development phase) i have a simple architecture that consists of two web services, one that manages authentication and identities, the other one that holds the applicative logic (business logic, updating db, ecc.).
I'm using JWT Bearer token for client authentication.
Everything works fine with my authentication service, but when I try to call the application service I obtain this error in the Chrome browser console:
Failed to load http://localhost:59207/api/Files/Upload: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access. The response had HTTP status code 500.
This error is preceded by another one:
POST http://localhost:59207/api/Files/Upload 500 (Internal Server Error)
Is, in some way, the second error I get related to the Internal Server Error it is preceded by?
I test my POST call from Postman and everything works fine, no server-side errors and the data i want back from my service is returned.
I already put in place everything I know about CORS in ASP.NET Core.
Startup class method named "ConfigureServices" contains, as first row:
services.AddCors(options =>
{
options.AddPolicy("AllowAll",
builder =>
{
builder
.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials();
});
});
Then this is called in the "Configure" method:
app.UseCors("AllowAll");
Also I put the EnableCors Attribute on every controller class like this:
[EnableCors("AllowAll")]
Anyone has an idea of how I can get out of this mess?
From what I get, this is how CORS is intended to be used and I already got it running this way on other projects (but never with ASP.NET Core 2).
Thank you in advance
This may not be an answer to your situation, but I've run into this issue quite often in the past. It's a Chrome issue when talking between two localhosts upon POST requests.
Try using another browser and see if it works; if so, you can continue using Chrome by disabling Security
chrome.exe --user-data-dir="C://Chrome dev session" --disable-web-security
hope this helps.
I have a very basic Single Sign On app built on VS 2015 using MVC and Web Forms. It is supposed to be a simple proof of concept and is based on some code found here and here which are essentially the same things. I've finally gotten it all converted to use .Net 4.5 but when running it on my local server it throws a 404 with no debug information.
The 404 itself wasn't initially a surprise as I was supposed to be able to change the url to one of the secure pages (for instance /WebSecApp1) which would redirect me back to the signon page but no matter what I put as the url I get the 404.
I've also tried changing the urls in the code so that they contain the port numbers for the localhost but that doesn't work either.
It was suggested to me that the RouteConfig.cs could be the culprit but I don't see how that could be since I'm calling a single page with no parameters.
I know this is kind of lite on details but does anyone have any suggestions?
Yes this looks like a routing issue as you also thought it to be. Routing is essential for web api too .Pls see https://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection. Does your api request look like this
GET http://localhost:34701/api/products/1?version=1.5&details=1
You do have to mention the port in the request.
While the routing that Arathy mentioned above was partially to blame, the real problem turned out to be relatively simple. In my case simply selecting Properties->Web for each of offending pages and setting "Override application root URL" to checked fixed the whole problem.