I am writing an ISAPI Extension on Windows 10 using VS 2017 and regular C.
It works great but now I am having trouble with error handling. I am purposely encountering an error to make sure the error message is correct. When the client app (not a browser) and IIS are on the same machine I get my expected error message. When I connect to a copy on another pc, I get the IIS generic html for the 500 status.
Here is where I generate the header:
// Send HTTP headers
SendHttpHeaders(pECB, "500 Internal Server Error", "Content-Type: text/plain\r\n\r\n");
SendHttpHeaders is my wrapper function for sending the headers. I s
Here are the last two lines of code:
pECB->dwHttpStatusCode = HTTP_STATUS_SERVER_ERROR;
return HSE_STATUS_ERROR;
Why am I not getting my custom message?
Unless IIS is configured otherwise, detailed error messages are only shown to browsers connecting from localhost.
While the linked post describes how to control this behaviour, note that this blocking is intended as a security feature, and (as they mention) depending on your site implementation, this can expose internal details to public view when error conditions are triggered (i.e. ones you are not expecting to make use of this behaviour, such as from a bug). This may or may not be a security concern depending on your operating environment (eg. public internet vs corporate intranet), data sensitivity, etc.
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'm creating a VS Code extension with a webview that contains a React application. In the React code, I'm making a GET request to a REST API, but it keeps failing due to the following error:
Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID
Any ideas on why this may be happening or a workaround? Maybe this is a restriction of webviews?
If I make the call in the extension code, it works fine.
I upgrade the version of my browser to the latest and it worked me.
find this below given link to know how to update browser version.
https://www.computerhope.com/issues/ch001388.htm
Assuming that you get this error about the certificate of the remote side (the one serving the REST API), you get this error because of one of the following:
the authority that signed the certificate is not recognized on the client side (ie : the authority is not installed on your PC)
the certificate has expired
your PC has a wrong date
You can correct the above, or as a workaround you can (depending on your tools) explicitly ignore the untrusted remote certificate. But this workaround should remain for test purpose only, as it is a security breach.
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?
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property
One of the users of a silverlight app I wrote gets this error message:
[Arg_VersionString] Arguments:
Debugging resource strings are
unavailable. Often the key and
arguments provide sufficient
information to diagnose the problem.
See
http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.50524.0&File=mscorlib.dll&Key=Arg_VersionString
I checked the log of the asp.net application that is hosting the silverlight plugin and I see no exceptions. The services seem to be working properly, I even witness the trace of this user running the app, and I can confirm that the service successfully returned data.
Something must be happening on the client side, but I don't know where to start. The software is in production already, there are no debugging tools on that server other than DbgView and the problem only seems to be occuring for this particular user.
What would you do?
In order to reduce the size of the Silverlight plugin, The strings of error messages were removed. So if any unhandled exception gets thrown this is the message you will recieve.
In order to get the full version of the exception the user has to have the Silverlight Developer Runtime and not the client runtime installed.
If you have a record of the data returned to the client, you might try using Fiddler to inject that data into the client running on your machine and see if it fails. If it does you should get back the full error message.