I have an ASP.NET application that uses the DocumentDB .NET SDK (latest version v 1.10).
I am using the new local emulator.
When the app is started locally, I am not able to see the requests made by my .NET SDK to local emulator in Fiddler. However, I can see in Fiddler the requests to local emulator made by the web application "Data explorer" (shipped with Local emulator) in my browser. I can also browse in Fiddler DocumentDB requests from my locally deployed web app on a remote DocumentDB endpoint (in Azure).
I suspect there is some configs to be set in .NET SDK so that requests are intercepted by Fiddler proxy.
We finally managed to find a solution with two things to change:
In documentdb client instanciation set connectionPolicy.EnableEndpointDiscovery = false; (do not push this to production)
And replace the documentdb endpoint url from https://localhost:8081 to https://localhost.fiddler:8081
You can use fiddler to see the request and response if you choose Gateway or DirectHttps mode.
When you use .NET SDK, it will not automatically direct to the fiddler proxy so that you won't see your request/response automatically.
You can either set the proxy in your app config
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
Or you can use https://localhost.fiddler, which will go through fiddler proxy so that request/reponse is captured. Note this option will make request to fail if fiddler is NOT running.
Are you using Direct mode while connecting to the local emulator?
Fiddler will not be able to intercept requests when using direct connectivity since it can only intercept http traffic. Changing the connection policy to gateway should allow fiddler to intercept the requests.
Related
I run a .Net 6 API on my Raspberry PI. I can get data from this API using the browser “https://192.168.178.51:7001/swagger/” . Also getting data from entering the url “https://192.168.178.51:7001/api/status/” returns the expected values. So the API is working so far. But when I try to get data from my Blazor WASM App using HTTPClient I get no data. Inspect the browser shows the following message:
GET https://192.168.178.51:7001/api/Status net::ERR_CERT_AUTHORITY_INVALID
How can I fix this? Do I have to install a SSL Certificate? How to do this for a self contained API?
You will need, at minima, a self-sign certificate. Then you will need to let your browser accept a self-sign.(Advance, Proceed to ServerIp)
Now, I do not know what OS you are using in your Raspberry, but for a Beaglebone(similar to Raspberry Pi) with Debian and nginx, here is the procedure
https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-on-debian-10
You will need the same kind of steps for which ever OS and webserver(Apache, nginx...Kestrel?).
Using a reverse proxy will be the solution, as described here: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-6.0
Quote from the article:
Kestrel is great for serving dynamic content from ASP.NET Core. However, the web serving capabilities aren't as feature rich as servers such as IIS, Apache, or Nginx. A reverse proxy server can offload work such as serving static content, caching requests, compressing requests, and HTTPS termination from the HTTP server.
Using a reverse proxy I can set a certificate.
If I host my Kestrel-based ASP.NET Core website with UseIISIntegration behind IIS, should the Server response header still say that I'm using Kestrel? Because it seems that it is:
Is it a correct behavior?
Short answer: Yes, it should still report the application as hosted by Kestrel.
When you use IIS to host an ASP.NET Core application, you're really using IIS as a reverse proxy to Kestrel. This is the approach recommended by the documentation:
If you intend to deploy your application on a Windows server, you should run IIS as a reverse proxy server that manages and proxies requests to Kestrel.
An incoming request will be handled first by IIS, and then passed on to Kestrel, like this:
Web -> IIS -> ASP.NET Core module -> Kestrel
So it's still accurate to say that Kestrel is the server handling the request. IIS is just sitting in front, helping Kestrel deal with the incoming traffic. You can check whether the site has been set up and assigned to an app pool in the IIS Manager if you want to determine whether it's using IIS (which should be the default).
Not exactly the answer to the question, but since Google gave me this related answer to my question it might help some people:
To remove this "server" header, an option has been added to the Kestrel Startup Options, so in program.cs you can remove it by adding the following option:
.UseKestrel(o => { o.AddServerHeader = false; })
Documentation (quite poor)
I deployed an Asp.Net Web API project on Amazon Web Services' Elasticbeanstalk (IIS configured machine). Everything works fine except WebSocket. To test the WebSocket easier I use Simple WebSocket Client extension on Chrome.
When I make a request to the API, I get the following (error) message (I observe this message over developer console's network tab):
WebSocket connection to 'ws://my_url' failed: Error during WebSocket handshake: Unexpected response code: 400
I have not found enough information to overcome this problem.
I tried enabling all Inbound/Outbound TCP connections from all ports and all IPs under Security Groups.
I tried creating an empty Asp.Net Web API project that only has a basic sample of WebSockets (just sending a message to the connected user) and deploying it to a brand new environment and application on AWS.
Nothing has worked so far.
I am using Microsoft's WebSockets, .NET Framework 4.5.1.
What are the possible solution ways?
If you are using AWS Elastic Load Balancer in your elastic beanstalk then ELB does not support web sockets and you have to apply a work around. Change your Load Balancer top classic load balancer that supports Websockets.
https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/
I solved the problem by adding All TCP on Inbound segment of Security Groups and using the IP address of the server instead of AWS created name.
I'm running my ASP.NET Web API app locally with xsockets without any problems. When I publish the project to Azure, it won't connect. I enabled websockets for Azure and adjusted the xsockets url on the client side
from:
conn = new XSockets.WebSocket("ws://localhost:50838/api/Chat");
to:
conn = new XSockets.WebSocket("ws://.azurewebsites.net/api/Chat");
Any suggestions?
Arnoud
XSockets passes in the subprotocol 'XSocketsNET' by default and for some reason Azure is filtering this away in the response. It works fine in emulation but on Azure the sub-protocol is removed. This causes errors in Chrome since chrome checks the subprotocol giving the error below:
WebSocket connection to 'ws://xmvc.azurewebsites.net/Home' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received
It works fine in other browser that does not perform this check. I've tried IE10 and Firefox on this sample site running XSockets on a Azure WebSite
In my opinion Chrome is doing the correct thing and Azure has a bug.
EDIT:
Be aware of the fact that Azure WebSites limits websocket connections!!!
Free site: 5 connections
Shared site: 35 connections
Standard site: 350 connections
According to Microsoft using WebSockets over Wss / Https will do the trick, i just done a test and the result is still the same.
Most likely the "unnecessary" sub-protocol header is removed from the response event if you pass is from server during the hand-shake.
So, You cannot rely on the SubProtocol when using Windows Azure as it seems?
So far I've been successfully using fiddler to sniff web service traffic from both test fixtures, console apps and web projects.
Today I noticed I am not able anymore to sniff that kind of traffic if I am running my web application (it's a ASP.NET website, hosted locally on IIS). I see all the local traffic but the web service traffic is just gone (the service is being hit as I do see the response debugging into the code).
I am still able to successfully sniff soap requests and responses from test fixtures or console apps in the same solution (exact same environment).
If it was a windows (I am on Win7) security update or the likes it would never work I guess (unless it affects only traffic routed through IIS).
What should I be looking for that could cause the emergence this behavior?
Any pointers appreciated!
NOTE: I can see local traffic, but not the SOAP request/responses to the web service which is not hosted locally anyway (it's a sandbox another team is providing)
EDIT: This bit of configuration did the trick (found on Rick Strahl's blog)
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:8888"/>
</defaultProxy>
</system.net>
What's the client of the web service? ASP.NET?
ASP.NET traffic isn't proxied unless you configure ASP.NET to use a proxy. It's possible/likely that the app.config or machine.config changed such that traffic is no longer getting proxied?
You should have a look at this section: http://www.fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET
If you want to view the http traffic between your web site and your web service on your development machine, and don't want to change your machine.config.
One easy solution is to change the Application Pool Identity of your web site to use your own credentials of the current logged on user. This means that your web site will adopt your proxy settings and will now redirect to Fiddler.
Make sure the web service you are calling (from IE) is not http://localhost/yourwebservice
Fiddler will not intercept localhost traffic from IE, use http://machinename/yourwebservice instead.
I ran into this issue a week or so ago. Try this page: http://docs.telerik.com/fiddler/Observe-Traffic/Troubleshooting/NoTrafficToLocalhosthttp://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic
The ipv4.fiddler was the part that worked for me. Hope this helps.
You're probably using a port other than 80 for these http requests. I remember setting up a reverse proxy to look at WCF requests I was making on my local machine during dev. Here's the documentation:
http://www.fiddlertool.com/fiddler/help/reverseproxy.asp
Can you try the following -
Try stopping the windows firewall and see what happens
try using firefox and redirecting traffic to fiddler and see what happens