I have API (.NET Core 3.1), Website (GatsbyJS) and mobile app (React Native). I'm deploying API on my Digital Ocean droplet, while website is hosted as Azure Web Static App. API is hosted on subdomain (api.mysite.com).
Locally, SignalR works fine for website and mobile. When deployed, SignalR works fine only for mobile while for web it's throwing errors. Handshake is okay but fails afterwards.
Some errors after few ways of trying to make it work:
There was an error with the transport
Handshake was cancelled
I tried using HTTP as well as HTTPS. Also tried to use skipNegotiation but that fails as well. I'm out of ideas on what I can try and what can be the problem.
Thanks
Problem was in configuration on Digital Ocean where API was hosted. More info how to solve websocket issue can be found here: https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-3.1#linux-with-nginx
Related
I am working on a Blazor(PWA) standalone app. Is deploying to a hosting provider required for standalone Blazor webassembly PWA? Or is it possible to serve the app from a network location for users to download and run it locally in their browser? I looked for documentation but can't find any. Please let me know. Thanks!
You'll need to host the app from an HTTP server that provides secure hosting (HTTPS). For example, you could set up an HTTP server on your local network, or use a hosting provider on the internet.
It cannot be shared from a network drive, or anything like that because it's not considered secure, and thus the service worker won't be registered.
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 develop asp.net core app whit SignalR and everything is Ok on the localhost. but when I publish the app on a server I receive WebSocket error.
my test app : http://test.gelimak.ir
Where are you publishing your app?
If it's self-hosted in IIS, you need to enable websockets https://learn.microsoft.com/en-us/aspnet/core/fundamentals/websockets?view=aspnetcore-3.1#enabling-websockets-on-iis
If it's Azure Web App you need to go to the WebSite settings and enable WebSockets.
I have followed the instructions here and here to setup SignalR in a ASP.NET Core web app. Then replicated the same code in a Service Fabric ASP.NET Core service only to find that the 100% working code when hosted outside of service fabric did not work when hosted on Service Fabric. When I open the html client included in both of these samples and turn on developer tools in the browser I see what appears to be the WebSocket handshake failing with HTTP 410 GONE errors.
In the Service Fabric documentation for ASP.NET CORE I found that the ServiceFabric Middleware can return HTTP 410 GONE if the identifier that validates each request does not match. But I guess I don't understand the inner workings of SignalR to know how to properly configure Service Fabric to unblock this.
I am running on a local single node cluster so I figured that I wouldn't have any issues until I needed to do multi-node cluster deployment, at which point I would need to figure out the SignalR backplane I'm going to use.
Any idea what would cause this to be?
I needed to disable Service Fabric Integration in the WebHost Builder. Simply replacing this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
with this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
allowed it to start working.
I created an asp.net mvc application that utilizes Google's analytic's API. The application was working for a short period, it then stopped working. By stopped working it is unable to make a connection to google. This problem occurs at my work environment. I tried the application at home and it works fine. I think my organization is blocking the application connection. I created a console version of the web app and it works fine.
Do web apps and console app make different external server requests?
How do I diagnosis the problem so I can make a request to the help desk as to what ports they are blocking.
thanks,
thanks for the help guys. I managed to route the api calls through a proxy server.
Application worked fine after that. Here is a link to using a proxy with the api.
http://code.google.com/apis/gdata/articles/proxy_setup.html
Try using Fiddler, is a HTTP proxy that maybe can five you the information that you need. Other option would be mabye using Wireshark, for scanning too, but I'm not sure about it cause I never used it.
You need to install the tools on the client that is making the requests to Google
I hope this helps