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?
Related
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.
I have deployed a staging server under a subdomain and serving it on IIS on a VPS. I published an ASP.NET Core 5 (RazorPages template) app and it is using default identity, requiring login before you can go to any other page. Obviously I want to realize the staging of different applications under this domain so on IIS, I have created a virtual directory under my staging website and pointed it to the physical location where I have deployed the demo app. Physically, the staging website and the demo app are next to each other, but on IIS there is a virtual directory application called /demo under the main iis website. "demo" is also an aspnet core mvc app.
When I type in the Url staging.mysite.com/demo it loads and working fine under its own application pool. What I want to achieve is to create a custom route in the main staging website that will be recognised as /demo (as if there was a demo controller or razor page dir) and redirect back to login if the user is not logged in. Right now it loads the demo app no matter the user is signed in or not. Is this even possible to secure child apps from a parent app? I have read so many articles and msdn documentation but obviously lack fundamental knowledge about IIS and the middlewares. I suspect IIS is not even forwarding the request to aspnet middleware/kestrel when it finds an IIS application on that URL. How should I approach this problem? Any leads will be greatly apppreciated.
Edit: I don't want the authentication on the main website to propagate into the child app. Just want to keep unauthorized access to the child app. Child apps have seperate logins and that is fine for now. Thanks.
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 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.
In this tutorial, they created an API using flask which you can post to and it will give a response.
It then tells you to make an Angular app which makes calls to the API.
How would this work on an apache server?
The tutorial doesn't mention this, but I've tried using a WSGI on apache that can run a flask file which can redirect to the angular app using
#app.route('/')
def index():
return render_template('index.html',content=content)
Is this a typical way to deploy an Angular and Flask app? It seems weird that the flask is calling the angular index.html, is there a way to do this with lower coupling?
What is the standard for using Flask as a RESTful API and also running angular on the same server?
Flask is a web framework and play the role of WSGI application in the protocol of WSGI. It needs a WSGI server to negotiate with http clients and then call your WSGI app to process http requests. Although Flask ships with a small WSGI server for development, you should use WSGI servers like gunicorn in production.
Angular app consists of static files which should be served by a http server. Nginx is the best http server for static files. But for simplicity, Flask plus WSGI server can serve these static files for you. So you will see
the flask is calling the angular index.html
When it comes to your questions
Is this a typical way to deploy an Angular and Flask app?
It's a typical way in development but not production.
is there a way to do this with lower coupling?
What is the standard for using Flask as a RESTful API and also running angular on the same server?
Serve angular files by Nginx.
Use gunicorn or other WSGI servers to serve Flask app.
It's also a good practice to use Nginx as proxy for WSGI server.
Any question?
Regardless which JS framework you use for web development, the javascript must be served within an HTML file. Here Flask is serving two roles, one is to serve that HTML file (and potentially the static files like js, css and images), and the other is to provide all the rest api endpoints. I don't think there's anything wrong with this kind of setup. But for production environment, you can use nginx or any web server to serve the static files and only use flask to serve the REST api calls. If your site doesn't have very heavy traffic, serving everything from Flask alone is fine too.