I have two separate projects
MVC Web App
MVC Web API
I have published both on my IIS 7.5
My Web App is hosted on 7172 port
and Web API is hosted on 7171 port
Strangely iam not able to call jquery.ajax() from my web app (7172) to web api (7171) port. It gives me 405 Method not found error code.
But if i write the same jquery.ajax() in my web api project (7171) and call web api method then it work fine and returns data.
I want to call web api from my web app.
Any suggestion would be appreciated.
Thanks in advance.
This has to do with the Same Origin Policy. By default, you can't execute an AJAX call to another domain (both on name, port and protocol).
If you want to enable this you should use Cross-origin resource sharing (CORS). CORS can be used with Web API by installing a (prerelase) NuGet package: Microsoft ASP.NET Web API Cross-Origin Support
This package allows you to configure which domains can call your service. You can find a walk trough here Enabling Cross-Origin Requests in ASP.NET Web API. In essence it comes down to adding attributes to your controllers like this:
[EnableCors(origins: "http://myclient.azurewebsites.net", headers: "*", methods: "*")]
You're running into the same-origin/cross-domain security policy. The port used is part of the origin calculation. A bit of Javascript loaded from (say) localhost:80 cannot make an AJAX request to localhost:8080, because the port numbers don't match. The 405 error you're getting is almost certainly coming from your Web App, not the API - check the server logs for the app, and you'll see the ajax hit in there.
Related
I've got Azure ServiceFabric web-app (AspNetCore 3) hosted over reverse proxy (NGinx). The app use AzureAD (in company) authentication. I've Registered App for the AD and setup Redirect Urls mannually in manifest. After publishing the APP and configuring DNS and reverse proxy I tried to authorize to my app but failed with AADSTS500117: The reply uri specified in the request isn't using a secure scheme.
Is it possible to configure client to allow http redirects?
P.S. As I know Identity Server allows it by configuring DiscoveryPolicy.
P.P.S. You can find more information in my origianl question (see. How to change redirect_uri for Azure AD)
What happens?
when you deploy web apps with a reverse proxy, as is, for instance the case with App Services as Linux containers, your application will be called on an HTTP address, whereas its registered redirect URI in the app registration will be HTTPS.
This means that when a user browses to the web app, they will be redirected to login.microsoftonline.com as expected, but with redirect_uri=http://<your app service name>.azurewebsites.net/signin-oidc instead of redirect_uri=https://<your app service name>.azurewebsites.net/signin-oidc.
How to fix it?
In order to get the right result, the guidance from the ASP.NET Core team for working with proxies is in Configure ASP.NET Core to work with proxy servers and load balancers. You should address the issue centrally by using UseForwardedHeaders to fix the request fields, like scheme.
The container scenario should have been addressed by default in .NET Core 3.0. See Forwarded Headers Middleware Updates in .NET Core 3.0 preview 6. If there are issues with this for you, please contact the ASP .NET Core team https://github.com/dotnet/aspnetcore, as they will be the right team to assist with this.
So I've developed an asp .net core API that has to allow cross domain access. I've been able to get everything setup and running. I've enabled CORS and want it to apply the same setting across all of my endpoints so have the following in my Config method:
app.UseCors(builder => builder.WithOrigins(
"http://localhost:3000",
"http://localhost:3001",
"https://staging.example.com",
"https://production.server.com")
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials());
And in my ConfigureServices method:
services.AddCors();
The code is before the MVC middleware and when running locally I have to send requests from localhost:3000 as all others are rejected/blocked (as expected).
Also on staging and live the app works fine and can call the API without any issues.
However, when deployed to the staging or production I can call the API from my local machine using Postman as well as by pointing my local copy of the web app (an AngularJS app) to the API.
Maybe I'm missing something or my understanding is wrong but I thought this shouldn't be allowed! And if not then any thoughts about where I may be going wrong? It seems as though my API is allowing any request from any domain.
CORS is only about ajax requests from web pages in domain A to domain B. Postman is a dev tool not a web page, and it doesn't care about CORS, that's why your Postman requests are not blocked. It is the same as building console application making http requests to your api, i.e. the requests won't be blocked.
Regarding the angular client, your requests are not blocked because you allow http://localhost:3000 and http://localhost:3001 origins. If you try ajax calls from lets say http://localhost:3002, it should be blocked
An option here is to extract the origins in config/json files. For example, you will have appsettings.Development.json with something like:
{
"cors": {
"Origins": ["http://localhost:3000", "http://localhost:3001"]
}
}
And additional files appsettings.Production(Staging).json when running in Production(Staging) environment.
If you want to totally secure your rest API, you should consider adding JWT authentication. For example, adding Identity Server 4 in the game, or using Azure B2C AD. But this mean that you should also add Login for the Angular client.
I have a question about enabling cross-domain calls.
I have a WCF Rest service that is hosted in xyz domain. I am able to test these REST APIs from Advanced Rest Client, Postman and Fiddler. I also have a WPF application that actively calls these API which is hosted in a different domain (say abc domain) which works fine in getting responses.
However, when I created a new Angular web application and a Windows Service (deployed on abc domain), and tried calling the APIs from these two components, I am getting a 405 error.
Can someone explain:
How REST clients always are able to successfully establish a connection?
How does my WPF successfully connects to the WCF service even though
its on a different domain?
Why is my Windows Service/Web App not able to talk to WCF?
I assume that the issue here is caused by the preflight request. The browser issues this OPTIONS verb request to ask the server if the origin is allowed to call the API in a non-safe manner.
If your WCF REST service does not deal with this request, the WCF runtime will try to dispatch the request to your service implementation.
However, if the runtime does not find a method to call for this verb, it will return a 405 Method Not Allowed response.
I've dealt with this in the past by using an IOperationInvoker implementation, installed via an IOperationBehavior. This article describes a slightly different way of doing basically the same.
I'm currently developing an HTML5 mobile web app for Blackberry using WebWorks that interacts with a 3rd party API.
Unfortunately i can't use the API directly from the mobile app due to the cross domain requests constraints, so i'm considering the development of a Web Proxy that interacts with the API and serves the web app.
Since I've never done such thing i would like to get some recommendations, i'm going to use Microsoft technologies (.NET) to achieve my purpose.
I'm thinking about a WCF service that makes all requests to the API and the mobile client connects to the WCF service to get the data, but i think i'll have the same cross domain requests limitation anyway so it might not work.
First, check with your third-party API provider if they support CORS. If they do, you can get around the same origin policy restrictions. Assuming they don't, you can create a facade service using ASP.NET Web API instead of WCF. ASP.NET Web API is designed from the ground up for creating HTTP services for broader reach and there is no SOAP involved.
From your ASP.NET Web API, you can make a HTTP call using HttpClient and simply pass the request to the third party API and echo the response back to your app. As you rightly said, the same origin policy restrictions will apply to this case as well but you have more control over the server side. You can implement CORS in ASP.NET Web API and that way your BB WW app can still call your web API despite being in different origins.
I'm developing a windows sidebar gadget that calls out to a wcf service via a javascript xmlhttprequest. If you stop the iis site hosting the service, shouldn't all calls to that service from the client return a 404 or something similar? The gadget and wcf service are running on separate machines. When I stop the iis site hosting the service and then drag the gadget from the gallery on to the sidebar, It is still populating correctly with data returned from the web service. However pasting the url for the service method into the browser correctly returns a 404. I must be missing something here.
I'm trying to reproduce a scenario where the gadget cannot reach the service so that I can test my xmlhttprequest error listener code.
Any suggestions are appreciated.
Is it using cached results from a previous request?