I am building a .net 7.0 core minimal web api in VS2022 and would like to be able to access the swagger index.html page outside localhost, for example from my iPhone over my home network.
I have tried adding my home ip address to the urls in launch settings.json to no avail and worked through various links such as configuring kestrel endpoints, Rick Strahl’s post on exterior kestrel endpoints, but still not able to connect outside local host!
I have tried running the application in both iis express and https debug settings.
You can use services like ngrock.
Check out this answer.
Related
Some background: I have a .NET Core API that serves as the backend for my Vue app. I've configured a bunch of environment variables in my Vue app that point to localhost:port to access that API. This works fine in my development environment, but now I'm trying to deploy this to IIS.
For now, I took the simple route to hosting my solution: both the API and the Vue app are on different sites in IIS.
I'm deploying the API as a web deploy package (using MSDeploy), and it seems to be working just fine. For the Vue app, all I'm doing is copying the npm run build output from /dist/ over to the site's physical directory in IIS. There's no web.config or anything (I wasn't sure if this was needed).
Here's the issue I'm running into: if I try browsing the Vue app on the server running IIS, everything seems to work fine, because the Vue app makes its API requests to localhost, which of course is valid. However, if I try browsing my Vue app from a different machine, it doesn't work because it's still trying to make requests to localhost on the "client machine", which obviously won't work because there's no API on the client machine.
I'm a novice when it comes to IIS, so I'm not sure if this is something that I need to address in my Vue app (i.e. by making the API URL/port configurable during deployment), or if it's a misconfiguration in IIS. Any ideas?
We are trying to migrate our REST Web API from being hosted as a Windows .NET Core 3.1 stacked web app to a containerized web app on Linux on Azure.
So far we have managed to push the image to the Azure Container Registry where it's being automatically picked up and successfully deployed to an App Service. Unfortunately, the app does not properly work yet. When trying to fetch some configuration data from a (anonymous) end-point from our API (GET https://foo.azurewebsites.net/api/configuration), instead of returning the data - as it used to do - I get a 301 (Moved Permanently) status code that points exactly to itself: location: https://foo.azurewebsites.net/api/configuration which leads to redirection loop.
So far I have no idea why I'm getting a 301 and I'm glad for any hints.
Points of interest:
Docker: the base for the image is: mcr.microsoft.com/dotnet/core/aspnet:3.1
Azure: Authentication / Authorization is switched off
Azure: no Front Doors are installed
The app is correctly serving the Swagger UI.
The Docker image works fine locally.
Here's how I solved the problem: it turned out that the cause for the permanent redirect loop was a conjunction of how the proxy works in the Azure deployment (thanks to Jason Pan for pointing me in that direction) and the following code that we had in our Startup:
services.AddControllersWithViews()
.AddMvcOptions(o =>
{
...
o.Filters.Add(new RequireHttpsAttribute { Permanent = true }); // REMOVE THIS LINE
...
});
Once I removed RequireHttpsAttribute filter, the app started working as expected. And since I've configured the TLS/SSL settings to allow HTTPS only, I think it is safe to omit the filter.
UPDATE 2021-01-20
I've just figured out that there's a better way to do this that does not require to remove the RequireHttpsAttribute filter. The core of the problem is that Kestrel does not know that communication is happening over a secure channel as the reverse proxy is forwarding requests over http to Kestrel. So we need to enable the forwarding of headers. For .NET Core 2.x applications this meant to follow the steps explained in Configure ASP.NET Core to work with proxy servers and load balancers. Luckily, for ASP.NET Core 3.x applications there a much more simpler way (that unfortunately is not mentioned in the official docs yet but was part of the preview 6 announcement): simply set the ASPNETCORE_FORWARDEDHEADERS_ENABLED environment variable to true. This can be done the usual way in the Azure portal under Confguration > Application settings:
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.
I am learning Asp.net Core Web Api. I need to access the api from a flutter application but am not ready to host the api on Azure. What are my options if I want to host the api locally on my computer so I can access it from another application like my Flutter app client, and is there any tutorials I can follow to learn how to implement the solution.
There are several ways to go about this, here are some options:
FROM VISUAL STUDIO: You can simply run the ASP.NET Core Web API from Visual Studio in Development Mode by Pressing F5
FROM COMMAND PROMPT: Run the API Project from the command line by opening a command prompt window in the root project folder of the project and use the dotnet run command. See here for more info about the command: dotner run command
HOSTING IN IIS: I am assuming you are running a windows OS. You can turn on IIS and its features. Simply follow the instructions on this page: Host ASP.NET Core in IIS on how to deploy ASP.NET Core to IIS. The advantage of this is that you have the application always running while you work on your flutter application locally.
I hope this helps you resolve your situation.
What are my options if I want to host the api locally on my computer so I can access it from another application like my Flutter app client, and is there any tutorials I can follow to learn how to implement the solution.
If your application is developing now, there is no need to host the application and let the Flutter app client to access. We could build some json file as the right format like web api response to develop the client app.
If your client application and web api has now developed successfully, you want to host the web api to let fluent app or other application to access from internet. You should have a public IP address and host the application on IIS or else. Public IP address you should ask for the IP provider company. Without a public address, the client side app couldn't access your application from internet.
If your web api and the client app are in the same intranet, you could let the client app directly access the web api after the web api hosted on IIS by using hosting server's IP address.
About how to host the asp.net core application on IIS, you could refer to this article.
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.