My project consists of 2 parts Silverlight and WindowsForms.
WindowsForm returns data at localhost:8081 or another port.
Data can easily see through the browser by typing the address, with the parameters on all computers.
If Silverlight is enabled on the local server everything works fine, the problems start when you run it on an external server.
On my computer everything works fine, but on some computers, an error is returned "Async_ExceptionOccurred".
Following the network turned out that Silverlight can't get clinetaccesspolice.xml, request has been sent but nothing happens, no error is returned. Of course directly in the browser can open the file.
After turned Fiddler bug disappears on some computers.
It follows that clinetaccesspolice and cross-domain set correctly. Something is blocking communication between Silverlight from external domain and localhost.
I found a solution. Maybe it's not too professional, but solves the problem.
Fiddler share its own engine for developers. Use it in the program used on PC. The engine will automatically change the proxy settings so the client does not need to know anything ;)
Fiddler core
// Call Startup to tell FiddlerCore to begin listening on the specified port,
// and optionally register as the system proxy and optionally decrypt HTTPS traffic.
Fiddler.FiddlerApplication.Startup(8877, true, true);
// Call Shutdown to tell FiddlerCore to stop listening on the specified port, and
// unregister as the system proxy if attached.
Fiddler.FiddlerApplication.Shutdown();
Related
I wrote a WCF service in visual studio 2017. I then added this service to IIS (not the express version but the full fledge IIS). It is added as an application under the default created website. I can access my service end-point without any issues at http://localhost/<websitename>/MyService.svc/test/123. /test/123 is just a simple GET endpoint.
The default website is already configured for port 80.
However, when I changed the port from 80 to say, 1234, it does not work. It merely returns me "Service Unavailable. HTTP Error 503." when I hit the /test/123 endpoint.
I have already executed the console command to add the port to ACL netsh http add urlacl url=http://+:1234/ user=everyone.
Does anyone know how can I get another port (non 80) to work?
Edit:
I am aware that there is an answer How to run WCF service on a specific port which explains how to bind to another port. However, the accepted answer uses the net.tcp protocol. I would like to use the HTTP protocol.
Is there any way to do it with HTTP protocol? If it cannot be done, then I guess ill have to redesign and swap over to net.tcp protocol.
I am extremely new to .NET development and WCF, so hopefully somebody with experience can point me in the right direction.
As it turns out, the problem had nothing to do with the so-called linked answer.
Prior to running my WCF service in IIS, I was trying to deploy it as a WAS and then Console application. In my process of getting those 2 implementations to work, I had to execute the command netsh http add urlacl url=http://+:1234/ user=everyone so that the port could be accessed.
By sheer luck, i stumbled upon this link:
https://serverfault.com/questions/666976/service-unavailable-if-i-try-to-access-iis-website-via-ip-address-works-fine-vi
Although it didnt have an accepted answer, the comments held the answer. My problem was caused exactly because I executed the netsh command. What happens is that the command causes that ip/port to be reserved, and thus, IIS cannot attach to the ip/port and therefore the Service Unavailable error. I assumed that if the WAS and Console version needed that command to be executed, then the IIS version needed it as well.
As for letting an IIS WCF Service be available on any other port, the process is super simple. Within IIS itself (Execute "inetmgr" in Run to launch), in the default or custom website you created, edit the binding and change the HTTP port to whatever port that you want. After that, its done. You should be able to access your application/website from that port via HTTP.
Eg:
http://localhost:<some port>/<websitename>/MyService.svc/test/123
My WCF Service config was a standard config that allowed for HTTP access.
If you would like to access it from another computer or from the internet, then you will need to configure your router to port forward your selected port (if needed) and ensure that your firewall allows data flow for that port.
Many "thanks" to the downvoters who assume this was some duplicate. Your "help" contributed in finding a solution to the problem.
I want to create an architecture as below
Web browser sends an http request. Web server accepts it and returns response to the another port to client machine. Windows service setted up at client machine will accept this reponse and process it.
I want to realize the project via Java applet. But Chrome doesn't support NPAPI. And Firefox also will terminate the support till the end of 2016. Therefore I decided to solve my problem by above way.
How can I realize it?
I wanted to know what is the best way to write an agent on Win platform that will be able to monitor browser's communication.
scenario: monitor the user access to predefined url on Chrome, FireFox and IE. On each hit I send the stats to a server with some data (page title).
The ways I found so far are proxy and browser addons. Each has it's own advantages and disadvantages. The main disadvantage of the proxy way is handling of HTTPS communication. The addon disadvantage is the installation (need to install on every browser) and cross-browser support.
Is there another way? some service I can write with .net that will automatically hook on a browser when it is started?
Thanks you.
You do have only two choices - an http proxy, or to write a plugin for every browser. That plugin could just forward data via network to a central service, leaving you with the challenge of coming up with a common set of data that all browsers can provide, plus learning all the plugin models.
In my opinion, though, the only real option is an HTTP(s) proxy because otherwise you have to keep updating your plugins every time browsers change, or deal with the fact that new browsers can come along and be used.
Certainly you won't find a 'user is browsing a url in some browser' event in the OS - all it knows is that a socket connection has been opened on some local port to a remote server's port 80/443 (or whatever).
So I strongly suggest building on top of the excellent work that's behind Fiddler and use the Fiddler Core.
http://www.telerik.com/fiddler/fiddlercore
For https you have to decrypt and re-encrypt with a different certificate. The information that you need is just not available without actually unpacking the request. Fiddler achieves this by opening it's own SSL tunnel to the target server on the client's behalf, whilst acting as an SSL server to the client under a different certificate. So long as the certificate that it uses is fully trusted by the client, no problems occur.
That said, it means that the user cannot personally verify the identify of the target site - therefore your system would have to assume worst case scenario for any invalid SSL certificates and block the connection.
I have a standard web server that serve web pages.
I want to monitor traffic on port 80, intercept every http responses, and add/inject an additionnal header to them.
The process will then act like a proxy between the web server and the client.
Could you please give me some pointers? I'm already aware of SharpPCap, but I'm not sure where to start.
Note: I can't rely on the web server, I can't control it or change it's configuration. However I can install any other process on the same machine.
Thanks a million
I think that SharpPCap is an overkill here.
Try:
listen on a port (say 8080)
for each incoming connection, accept and open one to the server (original one, port 80)
pass everything that comes in from the client straight to the server
pass everything that comes from the server back to the client, monitoring the stream and injecting/modifying if needed
I think what you want to do can be done with IIS 7.0 URL Rewrite module instead of rolling your own code.
http://learn.iis.net/page.aspx/711/modifying-http-response-headers/
I'm trying to parse a WSDL file which is in another server but has hard codded "localhost" all over the document.
When I fetch it, obviously the program complains "connection refused" because nothing is running in my machine.
My question is: Is it possible to use a webproxy ( such as fiddler ) to redirect those localhost request to my other server so the WSDL references are complete?
:-/
Thanks
p.s. I could always have fixed the remote "wsdl" but the guy on charge will be here until next week and I would like to start working today.
You could use Fiddler as the proxy from your machine, and then have it rewrite the WSDL to change localhost to the correct machine name.
The FiddlerScript CookBook has an example on how to write this sort of script. Go to that page and search for "Remove all DIV tags (and content inside the DIV tag)". Just change the regex to match localhost and set the replace to the machine name you want to use.
If you have SSH access to the machine, you should be able to use SSH port forwarding to accomplish this. I'm assuming you're using Windows (based on the C# tag), so you can use Putty as explained here: Using port forwarding with PuTTY. Just follow those instructions to forward the desired port on "localhost" to the server that serves the WSDL.
Alternatively, if you're on a *nix based machine or a Mac, use SSH w/ the following command:
ssh -L PORTYOUWILLUSE:localhost:PORTONSERVER username#serverhostname
For example, if the WSDL were served on port 80, you could do
ssh -L 80:localhost:80 username#server
Once you're logged in (with either method), any requests to localhost on port 80 will be rerouted to the server.
If you only want to change it for a few minutes while you parse the WSDL, you might be able to change the HOST file and point "localhost" to the remote IP address. The hosts file is in "C:\Windows\System32\drivers\etc" in Windows VISTA/XP.
There's a few ways you could achieve this, none are particularly robust as long-term solutions, but you mention you just want something temporary until the dev gets back.
If everything after the domain matches (if your remote URL is otherwise the same as the localhost one), you can edit your localhost entry in your hosts file.
In system32\drivers\etc, copy the "hosts" file onto your desktop. Open in notepad and change this line:
127.0.0.1 localhost
Change the IP address (127.0.0.1) to your remote domain. Then copy the hosts file back into the etc directory. (Note: it's not possible to edit this file directly, as Administrator or otherwise).
If you have multiple domains on the remote web service, in IIS, you need to change the web site to serve for requests to "localhost", this might seem a bit odd, but it'll work because your machine will make requests to the server's IP address, but specify the request domain as "localhost". Right-click the website in IIS and select properties, then add the domain "localhost" to the list of HTTP-Header values supported by that web site. You can ignore all of this if your web site in IIS will serve content if you access it via an IP address. If that single IP address is shared between multiple web sites (which is usually the case), you'll get a "Bad hostname" error from IIS as it attempts to look up "localhost" and can't find which web site to direct the request to.
Another possibility is to use a personal proxy server called Proxomitron. It's a little old, and no longer under development, but it's very easy to setup and very solid.
Once you've installed it, open it and click "Config" - change the port it listens on to 80. Next you need to create a redirect rule (it's not actually a redirect, more of a rewrite of the url). You'll need to have a quick read of the docs to understand how to add your own redirect, but there's plenty of samples that ship with the app. The rule you're looking for is RDIR:
$RDIR( ) Is more sneaky and redirects the connection in Proxomitron without telling your browser. This is useful when you want your browser to think it going one place when, in reality, it's going somewhere else.