I'm build a project using SignalR.
As Front I'm using .Net Core, as Back I'm using React.
So in my localhost the project is working, but when i deploy this project i get an error.
In azure I have created:
2 web application - one used for cliend, and the other one for server.
1 Azure SignalR service (i tested it online and it worked)
1 Azure SQL Database
So when i try to invoke Method it now working and show me this error. Someone know how to solve this problem?
Please check this ASP.NET Core SignalR connection
troubleshooting | Microsoft Docs which helps to check errors
that can occur when trying to connectto an ASP.NET Core SignalR hub.
One common cause is that app enforce HTTPS by calling
UseHttpsRedirection in Startup, or enforces HTTPS via URL rewrite
rule.
So If it is the cause try to change the URL on the client side from
"http" to "https". like > .withUrl("https://xxx/HubName")
Also please go through c# - Could not connect to Azure SignalR Hub -
Stack Overflow And check if the signalR url endpoint for client
is correctly given
var signalrUrl = "https://myazuresignalr.service.signalr.net/client/?hub=yourHubName"
Please note that sending the exception this way to the client is
insecure .So try to either throw a HubException or set
EnableDetailedErrors on the server.See HandleErrors when :Use
hubs in ASP.NET Core SignalR | Microsoft Docs
Reference:
Invoke hub's method which throw ArgumentException, client gets
HubException: An unexpected error occurred · Issue azure-signalr ·
GitHub
So the problem was that my Database was empty... the migration did not upload, Update the database solved it.
Related
I am developing a .Net Core (3.1) web application hosted with IIS 10. When I am trying to use SignalR on localhost, I am able to connect totally fine and receive messages from the backend, but after I publish it to IIS, I get the error: "Server returned handshake error: Handshake was canceled." In the client logs on Chrome's console, I get the message: "Information: SSE connected to http://myserver.com/MyApplication/output" before I get the error described above (which you would think means that I connected successfully)...
I have seen other posts where people have suggested that I have to enable webSockets on IIS, and I have already checked the my site has this enabled.
I have also seen people suggest to try using the longPolling argument in the withUrl function when creating the connection, and this has not helped either.
I have also added SignalR Event Log Trace Listeners to my web.config file, and the only warning I get that might be related to this issue is that I get a warning from the .NET runtime that reads "Failed to determine the https port for redirect." I am not sure what this means or if it would be related to SignalR, but as this also appears to deal with Middleware, it might be significant.
One thing that I thought might be related is that my site is just one of multiple hosted on this server, so that when I am running locally, I can use the following to connect to SignalR:
hubConnection = new signalR.HubConnectionBuilder().withUrl("/output").build();
But because of the way this site is deployed on my server, I have to use this:
hubConnection = new signalR.HubConnectionBuilder().withUrl("/MyApplication/output").build();
when I deploy the site or else I get a 404 error...
Would there be any issue there? I noticed when inspecting the network requests that on localhost, the URL to connect with the socket is "wss://localhost:44315/output?id=..." and I get the "Status Code: 101 Switching Protocols", but after I deploy, the url that is used is "http://myserver.com/MyApplication/output?id=..." and I get a "200 OK" just before receiving the error described at the top. Why does wss get used on localhost but http is requested from my client when I deploy?
FINALLY discovered the issue after days of debugging... The reason I was getting a "101" response on localhost and not when published is because 101 is basically the server (IIS in my case) saying "I support web sockets". I realized that because I wasn't getting this when published, web sockets were probably not enabled in IIS. It was weird, however, because I went into IIS manager and it said that web sockets were enabled, but after much more research, I found that you also have to go into "Server Manager" and enable it as well (see here https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support and follow step by step instructions). I did not realize both were required.
I have a Blazor WA Application that is using Identity Server 4 Service for authenticating users. Everything works fine locally. The issue comes when I try and publish to Azure. Since the IDS is published at one address and Blazor at another, i get the X-Frame error when calling from "https://blazor..."
"Refused to display 'https://identity...' in a frame because it set 'X-Frame-Options' to 'sameorigin'."
I've added
builder.Services.AddAntiforgery(options =>
{
options.SuppressXFrameOptionsHeader = true;
});
to the Blazor startup and to the Identity start up (just for giggles) but the error remains.
Any ideas?
TYIA
The short answer is to set the CORS settings in Azure to allow all (*) or the specific URL in question "https://blazor...".
I had done that at one point but for some reason it didn't work. After consulting with an Azure tech we tried it again and it worked.
¯_(ツ)_/¯
I am trying to create an Event using Microsoft Graph SDK, as following the document #
https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-beta&tabs=csharp
1.Created "authProvider"
2.Created GraphClient with above AuthProvider
3.Creating Event using
The event is not creating also no exception/error is throwing, Could any one help me here?
This is happening because this call is being made with same transactionId frequently. It avoids unnecessary retries on the server.
It is an optional parameter , just comment out this property and try again. It should work.
Note : This identifier specified by a client app for the server , to avoid redundant POST operations in case of client retries to create the same event and also useful when low network connectivity causes the client to time out before receiving a response from the server for the client's prior create-event request.
More info is required here, as the reply from Allen Wu stated. without any details I would focus my efforts on the authprovider piece and azure app registration piece. as the rest of the example is just sending a post request to graph api.
but what is recommended really depends on what type of application you are trying to build. eg. is it a service daemon, a web app, mobile app, desktop app, single page app, etc.
Background: I am working on a product which is built using AngularJS in the front-end, and Microsoft Web Api in the back-end. The website is hosted on a Windows Server 2012 machine running IIS. We are using Windows authentication to connect to the machine.
The problem: Calling various API methods work flawlessly for me and the majority of users. But for some of the users, they cant perform certain API calls. Most of the endpoints work and return valid data, but a few methods never even gets reached.
This is the error in the iislog: 2016-05-26 12:25:23 xx.xx.xxx.xx POST /api/controller/method - 80 domain\user xx.xx.x.xx Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.1;+WOW64;+Trident/6.0) http://xxxxxx.com/#/Pagename 500 0 0 514
In the console in google chrome it says: Error: Access denied.
I have set the api to log all exceptions to a database, and no error is shown. So my theory is that the api doesnt even get reached when trying to perform these specific http methods.
I have tried searching for answers, but without any luck. Does anyone have any idea?
I finally found a solution to my problem, the exception being thrown was a DbEntityValidationException. It was thrown because some of the users names were too long to be inserted into the database table. It was not catched and properly displayed by my own general exception handling. I had to follow this guide to get the proper exception logged:
https://stackoverflow.com/a/6258174/3592773
Thanks for all the help and I hope this might help someone else in the future.
I have a SL navigation application, that currently runs on a shared hosting package with a 3rd party ISP. I can login, and register using the ASP.NET membership and role providers.
I have now setup a dedicated server, on which only my app will run. It does not yet have a domain name that points to it... I access it via an IP address.
I've copied the entire site (including the ClientBin and all the XAP's) to the new server, but the Authentication and Registration services don't work... they just return NotFound.
When I check Fiddler on the working site, this service is called :
www.myaddress.com/ClientBin/MyApp-Web-AuthenticationService.svc/binary/Login
which of course succeeds. However, on the other site, the fiddler trace looks the same (because I just copied the site) :
123.123.123.123/ClientBin/MyApp-Web-AuthenticationService.svc/binary/Login
but, the call fails with NotFound. Fiddler reports it as HTTP/1.1 500 Internal Server Error. When I open
http://localhost/ClientBin/MyApp-Web-AuthenticationService.svc/binary/Login
on the server, I get the HTTP/1.1 500, as well as this description :
Handler "svc-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Which leads me to believe that there is something wrong with my IIS config, as the exact same code is working on another system.
What is a "bad module"? How do I fix it?
Normally this type of error is that ASP.Net is not activated or that a handler for svc is not registered or registered correctly.
In your case is looks a bit different. It could be that you have .net framework 4.0 code that you are trying to run in a .net framework 2.0 application pool.
IIS 500 errors often show up with more information in the Windows Event log - if you can somehow get access to that?
Also I've noticed that often the server will actually send debugging output back to the client that everything seems to ignore. Have you checked the entire raw response that is coming back from the server to see if there are any clues there?