I have implemented a Blazor application with Signalr which works fine locally, but when I deploy it to a server with IIS it throws:
blazor.server.js:15 [2021-03-11T15:35:28.868Z] Error: System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (Bad Request).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.NegotiateAsync(Uri url, HttpClient httpClient, ILogger logger, CancellationToken cancellationToken)
When I compare what Is happening locally with what is happening on the server it looks like it is this request that fails
[2021-03-11T15:54:20.865Z] Information: WebSocket connected to wss://localhost:44312/_blazor?id=VQLOPgZDJ-bXAb1CqhG1Vw.
I'd highly appreciate some help? If you need more information, let me know. I'd be glad to provide it for you.
Make sure the Websocket protocol is enabled in your IIS install. Do this via Roles and Features in Server Manager. Official documentation is here.
Related
My underlying issue is: A HTTP request gets serviced by the default servlet instead of the one I'm expecting.
Logging gives me information like this during server start
WFLYUT0021: Registered web context: /some/path
and still, curl -i http://localhost/some/path doesn't end up in my servlet, but returns HTTP 302, redirecting to /some/path/, which then gets served by Undertow's DefaultServlet. So how would I diagnose this type of issue?
Is there a way to see all deployed servlets in a Wildfly with their deployment info?
Is the Admin Console any good and if so, how?
When trying to run a request through swagger UI, I receive the following response on Swagger
TypeError: Failed to fetch
After searching around, I found that a possible cause of this error is because of a CORS issue, where the origin is changed in the request (as you can see at this other post here). However, in my case, this is not running through some other proxy, it is hosted on a locally hosted server and that server is not changing any of the headers. I realized this when I tried to allow the API to just accept any CORS headers to test if this was the issue; sadly it was not and the issue persisted.
The API is running on IIS hosted on a server that is hosted locally. The API is running as an application on the default website and is accessed via the following url:
http://servername/application-name/swagger/index.html
Can anyone help with this issue?
After further investigation, I found that when I looked at the requests being sent to the server through the dev tools on the browser, that the URL was being changed from http to https on the request of the endpoint through swagger.
HTTPS, has not been set up on the server and returns a 404 (as seen in the dev tools).
It turns out, that even though the server has not been setup to serve content via HTTPS, the requests where still redirected to HTTPS and this was the reason
app.UseHttpsRedirection();
So, even though swagger was able to be loaded on HTTP, when the request was made to the API, the API responded with a 307 - for redirection and the request was redirected to HTTPS - which in turn returned 404. This 404 response was the cause the TypeError: Failed to fetch
The recommended fix for this is to turn off https redirection (ONLY FOR TESTING PURPOSES) and the other is to enable the server to serve the content correctly over HTTPS, so that when a call is made, it is not redirected, but rather sent straight to the correct API address on HTTPS - which should not return the data correctly, since the server can serve HTTPS content
I created .Net Core Rest API service with two GET method. Locally in debug mode, everything works as expected. When I deploy this service on Azure Kubernetes service and behind API Management, on every call to these two GET method I receive HTTP 405 error. I tried with different endpoints, but any of cases didn't resolve this issue. Any idea?
We have a problem we're facing while trying to authenticate with ADFS,
We have two environments (dev and prod), both configured the same way, windows server 2012
In dev everything works fine, but in prod we are getting the following error:
Exception: The remote server returned an error: (401) Unauthorized.
Message: The HTTP request is unauthorized with client authentication
scheme 'Negotiate'. The authentication header received from the server
was 'Negotiate
oXAwbqADCgEBomcEZWBjBgkqhkiG9xIBAgIDAH5UMFKgAwIBBaEDAgEepBEYDzIwMTYwMjAyMTUyOTI2WqUFAgMM8+6mAwIBKakLGwlIUlQuTE9DQUyqGjAYoAMCAQGhETAPGw1TVkMtQURGUy1QUkQy'.
Inner Exception: The target principal name is incorrect
We don't know what to do, we've checked every ADFS configuration and everything looks fine.
An SAML trace using SAML tracer (FireFox extension : https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) could be useful in your case to decode the SAML Request and Response in order gather more information about your issue.
I have an IIS-hosted, WCF web service deployed on a UAT web server. In IIS, I have site bindings on this same web service--one for internal access (Ex: uat-nodotsinternalonly) and one for external access (Ex: mysvc.uat.mydomain.com).
When I use SoapUI to test against the internal host name (http://uat-nodotsinternalonly/MyService.svc), it calls the service and returns the response envelope as expected.
When I use SoapUI to test against the external host name (https://mysvc.uat.mydomain.com/MyService.svc), it calls the service and returns the WSDL HTML as would be seen in the web browser instead of the response envelope as expected.
We need to expose past our firewall for testing with a vendor. Our external client can browse to our web service using the external host name and receive the WSDL back in their web browser, but when they call it, it fails with a 302 error.
I’m far from an expert on security, but I believe our firewall is handling the security then forwarding over http to the UAT server. The redirect and variations seem as though there’s something to change in how DNS is managed or settings in IIS. Does anyone have suggestions as to how to narrow it down so that the call to the external service will work?
We too had a WCF service that in SoapUI was returning the WSDL HTML instead of the expected response when invoking a method. This was an SSL-enabled service, and the solution in our case was to edit the endpoint URL after creating the request so that it used https instead of http. This is because we found that for some reason it defaults to http even when you initially specify https when creating the request. Here's how to edit the endpoint URL in SoapUI:
In the request window, click the drop-down arrow on the URL.
Select [edit current..]
Change http to https, and then try your request again.
The problem with the client getting a 302 error was because the client was not sending a SOAP request envelope to our web service. The client was just sending XML.