I have two blazor server (.NET 6) apps running as app services in Azure. The apps are to be "hidden" behind an application gateway to give users the impression that they are visiting the same site. Traffic is to be directed using parts of the url i.e {{domain}}/* go to app 1, {{domain}}/{{keyword}} go to app 2.
This has been set up, using routing rules on the gateway and the routing works as expected, with requests reaching the correct apps. However, when reaching app 2, the websocket immediately disconnects, killing blazor in the process. Error message displayed in the console of app 2. The apps are very barebones, containing very little code as this is a POC.
Things I have tried:
Use Azure SignalR and not using it.
Configured both apps to use websocket
Use different routing rules for the two apps and use the same routing rule with two backend pools.
Use Azure Front Door, but the same issue persists.
Randomly toggle settings
Added options.ServerStickyMode = ServerStickyMode.Required; to the signalR config in program.cs
Added `#inject Microsoft.AspNetCore.Http.IHttpContextAccessor _HttpContext
#{
_HttpContext.HttpContext.Response.Headers["Cache-Control"] = "no-store";
}` to _Layout.cshtml with the _HttpContext. yadayada both inside the body and outside.
Maybe the most frustrating thing is that it works just fine when reaching the first app. I have tried switching the deploys, i.e. deploy app 1 code to app 2 service and vice versa, to no avail.
Have anyone else experience a similar thing? Any config or code changes I have missed?
Related
I build a web based mobile app (using react), which I'm hosting as an Azure Web app. This website is connected to a node server, which I'm hosting using a azure virtual machine (I don't know if this is the best approach, maybe I should host this as a webapp instead of VM ?).
I'm still new to this strategie of developing a web based mobile app and connecting it to a hosted backend in the cloud so I apologize if this is a trivial question.
I'm using websockets to connect my frontend to the node server and then I consume messages. I don't have a database it is a simple application.
The steps I'm doing to run the app are:
I connect to the Azure VM from my laptop with ssh
run my server using node server.js
When the server is runing, I can refresh my website and everything works fine
Now, the problem is that I want the node server to run all the time. However, I noticed that the server stops running when I deconnect (ssh) my laptop from the virtual machine. So I find myself doing these steps (connecting to the VM with ssh and running the server manually) each time I want to use the app.
Is there a way to do this so that the node server runs all the time without stoping? Also since I'm new to this, is this the right way to deploy frontend and backend? I assume I can't deploy both frontend and backend in the same Azure webapp or am I wrong?
(Since part of your question is around "Is there a better way?", I would answer that instead of fixing the issue in your current VM hosting :)).
To take full advantage of cloud for your applications, PaaS is always preferred over IaaS. In this case, unless you have any specific reason, you should deploy your backend Node app in another App Service (aka Web App). Or you can consider Azure Function also if your node app has a small set of APIs, but it will require code update. Both support multiple platforms including node.js. Since you mentioned you are leveraging Web App for your react mobile app, so I hope you are already bit familiar with it. Also since Azure Function would require code change, so Web App is preferred this case.
Note: I omitted other solutions like AKS, Service Fabric etc. for now, since currently we are talking about the problem of deploying only a single app, for which those will be overkill at this moment.
Also, to your point
I assume I can't deploy both frontend and backend in the same Azure webapp or am I wrong?
Yes technically you can, depending on your scenario by "bundling" into a single app if both are in same platform (like Node in this case). Though whether one should do that would be an opinionated answer. But even if you keep those separate, you can still leverage single App Service Plan for cost saving. So keeping separate like you have now is what I would suggest to maintain "separation of concern".
We have an Angular5 application with a DotNet OData backend API. The application is hosted in a Web Application with a virtual directory for the Angular5 app and another virtual directory for the DotNet backend. The web application is secured by Azure AD, with an Azure AD Application defined for the web site.
This all works perfectly. We have no authentication code in the front end (except for 'withCredentials: true' set in the service calls) but apparently having the whole application protected by Azure AD makes the front end able to call the backend without issue (Azure makes you authenticate when you access the Angular5 front end).
The problem comes when we try to develop the front end. When developing Angular5 one needs to run the Angular5 code locally, so I've set up a web app which hosts only the backend code and point the local configuration for the Angular5 app there. This fails with the first backend call with a 401. One of our developers discovered that if you simply plug in the URL to the backend with the same browser (i.e. copy the failing call from the browser network developer tab into a new browser tab in the same browser) you will go through the authentication process and then when you run the local Angular5 app again it works. We thought we had found a workaround until we noticed that for some reason this only seems to fix the "read only" calls. GET works, OPTIONS works but POST fails with a 401. I put some debugging code in the backend but it seems this code does not even get called (i.e. Azure, not our backend, is blocking the call).
So I've tried to figure out how to get the local Angular5 instance to behave as the one hosted by the Web app but I can't figure out what I need to be doing. I have also been unable to find anyone else doing this so I can't find a solution.
I have tried various solutions of actively getting a token (e.g. setting up /.auth/me, using adal5 to "login", etc.) for the front end but it seems every possible solution is defeated by CORS in the end. Our backend has an Allow-Origin for localhost:4200 but this doesn't apply to login.windows.com for the authentication step. I tried putting localhost:4200 in the CORS setting on the Azure Web App but then it complains about an Allow-Authentication header being missing and I have no way to force Azure to provide that. I read online that this is happening because Azure didn't expect people to be using "cookie authentication" so after some research I found that "cookie authentication" was being used because of the "withCredentials: true" calls, so I changed all of those to false. Then the Allow-Authentication failure goes away but I just run into more CORS failures during the authorisation (login.windows.com).
So I'm really stuck here. I can't believe I'm the only person on earth who's trying to run a local instance of Angular5 against an Azure AD secured Azure Web app backend but I can't find any examples anywhere of people successfully doing this. I also would like to avoid having to do some elaborate local authentication because the code works perfectly as-is when hosted on the same Azure Web app as the backend. Does anyone have a setup like I describe that is working?
I have two Web Apps, inside the same App Service. One is a back-end portion (with API on it, using .NET Core, SSL cert installed) and the other one is the front-end (ReactTS, created using create-react-app).
When I try to call the API method (an Auth method) using my Front-end I got this message as response:
Login failed: The resource you are looking for has been removed, had
its name changed, or is temporarily unavailable.
-404 error
Another fact is, if I run my ront-end solution locally, I can use the API (published on the Web App), normally.
My API URL is set inside the package.json file, as proxy.
My first thought was about an CORS problem, but it throws a 404 error.
Any configuration that I can do on my Azure, or something that I need to change in my application to allow my front-end to communicate with my API?
If we publish two web applications to one Azure Web App, the later one will cover the first one. It will cause that the first web application can't work. I suggest you create different Azure Web Apps for your web applications. You could choose one Azure Web App Plan for your Azure Web Apps. It will not add extra costs except for Shared plan.
If you use Shared App Plan and don't want to increase the extra cost, you could add a virtual directory to your Azure Web App. Then you could publish your second web application to the virtual directory. To create a virtual directory, steps below are for your reference.
Azure portal -> Web App Panel -> Application settings
I am trying to setup IP Based SSL instead of SNI SSL on an azure Web App.
The App Service Plan is Standard S1, but unfortunately I am getting the following error message:
There are no IP addresses in the App Service Environment that are available to be assigned to your app.
What are the possible options?
I believe moving the current Web App to a different App Service Plan in a different resource group would solve this issue. I Have already tried moving the App service plan to a different resource group but failed.
Note: Clicking the scale up button doesn't work and shows a JavaScript error in the console
JavaScript Error found in Chrome console
Byron is correct that this is a bug in the UX.
A fix has been made and should be live later today.
Your app is being hosted in an App Service Environment.
Looks like the scale up bottom is not working and that is probably a bug in the UX.
As a workaround you should be able to go directly to the App Service Environment that is hosting your app and perform the scale operation there.
once the scale operation in the App Service environment is done and the new IP Address is added, then you should be able to come back to the SSL binging UX in the app and try this again.
I recently discovered that one of my server machines had the same service under different Web Sites and they were managed by different app pools. Something like this:
Custom Web Site
MyWebSite (Managed by CustomAppPool v4)
Default Web Site
MyWebSite (Managed by Default App Pool v4)
The CustomWebSite version is hit on http 28000 port. The default one is just set up on 80 (this is not really hit)
Both the Web Sites are pointing to C:\inetpub\wwwroot. The Default Web Site version should not have been converted to an application in the first place. My question is how bad is it? Should I be separating the service asap?
My understanding is that IIS will handle the requests independently, so there should not be any danger in sharing code files. Other than it being untidy and allowing potential process issues, I don't think you have to remove it. On the same token, I believe you would be fine to remove it.