Is it possible to use browser's internet connection for other application?
I'm in environment where browser is the only application that may access internet connection. Meanwhile, I need to run maven projects which needs internet access to download the required JARs.
I was thinking about creating Proxy Server in Chrome extensions or other browser. But, I hope I can find another easier way.
Sounds like Selenium WebDriver is what you need. You could try to redirect the download to browser or try to programmatically simulate browser.
Yes it is possible.
Recently I created a http_proxy server in Java which start 3 socket servers:
Http server to receive user request, and
WebSocket server to allow Chromium extension to create connection to the http_proxy server.
Http Server to receive response body from Chromium.
So, there will be 3 socket connections:
To receive http user request and send back the content, and
To send the URL requested to Chromium browser
When response received by browser (via Xhr), it will do HTTP POST to http_proxy server to send the content.
That's all!
Related
I am trying to load test WebRTC server using JMeter.
The wss URL works fine in browser, but in JMeter it is returning 400 error in WebSocketOpenConnection.
URL that I am trying to hit is :
wss://myserver Port 3004 Path socket.io/?userId=K&EIO=3&transport=websocket
Same URL is opening properly in Chrome.
JMeter logs:
2022-09-08 16:27:53,195 ERROR e.l.w.WebSocketClient: Ignoring user supplied header 'Connection=Upgrade' 2022-09-08 16:27:53,195 ERROR e.l.w.WebSocketClient: Ignoring user supplied header 'Upgrade=websocket' 2022-09-08 16:27:54,320 ERROR e.l.j.w.PingPongSampler: Sampler 'WebSocket Ping/Pong': there is no connection to re-use
Any idea what am I missing?
Thanks
If you have only one WebSocketOpenConnection sampler in your Test Plan that explains a lot.
Your JMeter test must represent a real user opening a real browser and accessing your web application with 100% accuracy and as a real user using a real browser you first should send a HTTP GET request to the page mainly to get some cookies which may be required for successful establishing of the WebSocket connection.
Once done you need to implement protocol upgrade mechanism to create the session.
And only then you should try to open a WebSocket connection and start sending and/or receiving messages/frames.
So you need to create the same network footprint as your browser (or other application) does and then the request will be successful. And don't forget about correlation of the dynamic parameters as this K&EIO user ID seems to be something generated.
I have a setup which involves devices connecting to a server via web sockets. I'm experiencing a strange problem where they can connect to one test server without issues, but cannot connect to a different server (hosted on Azure).
I've installed Wireshark on both of them, and can watch both the successful connection and the unsuccessful connection. It appears that the unsuccessful one attempts to initiate an SSL handshake.
Here is the successful connection:
Here is the unsuccessful connection:
It seems like the client in the successful connection is simply setting up an HTTP web socket, but in the unsuccessful setup it's try to set up a secure connection.
Why would the client be setting up different connections depending upon the server address?
The client code to create the websocket is just javascript, invoking new Websocket(address), and in both cases the address begins with the 'ws' prefix.
I have done some further investigation and found another weird behavior. As it happens, there are two domain names pointing to the same server.
If I used the domain name with the top level domain "com" (XXXX.australiaeast.cloudapp.azure.com), then the connection works.
If I used the domain name with the top level domain "dev" (comutername.mydomainname.dev) then the connection fails, with the weird TLSV1 packet.
Both works fine if I run the same client code on the Microsoft Edge browser.
This appears to be a defect in Chrome's implementation of The WebScoket API
I have posted a defect here, let's see how it goes. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076
The issue in play here is HTTP Strict Transport Security (HSTS)
A browser can be configured so that certain domains have an HSTS policy attached, meaning any insecure link will automatically be converted to a secure link.
This policy will be applied if a request returns a Strict-Transport-Security header. But, and here's the significant bit, the Chrome and Firefox browsers automatically apply the policy to all dev domains.
It appears that up until recently, the Chrome browser and Chrome OS was not observing the policy with regard to WebSocket connections. This has changed, and now WebSockets will observe the HSTS policy.
The upshot is, if you have a websocket using the ws protocol and not the wss protocol, and it's on a .dev domain, your Chrome and Firefox browser will not be able to connect to it.
I'm running a local web server written in Go and I can debug traffic going to it from my browser; but, I can't see the http request that it makes to external services.
Do I have to run some particular configuration of the web server in order to get the traffic to appear in fiddler? It is running as a background process.
Short answer: you can't...
...unless your web application is written to open a connection to a Proxy server and route requests through that connection (e.g. connect to a remote proxy, and then send requests through it).
Typically what developers do is just dump the Web Request/Response to a debug file to inspect during development (or to debug on a live server, by enabling it with a flag at runtime).
Fiddler is a "proxy" service/server. When you are using it normally to debug browser requests, your Browser is configured to connect to a Proxy server. That is, it will send all web requests through your fiddler's local server (I think it's localhost:8888 if i remember from my Windows days of using Fiddler) which in turn makes a connection to your local web server that you are debugging.
You can read more about Proxies at Wikipedia.
In that picture above, your local web server would be Alice. Meaning, Alice would need to be configured to connect to a proxy server and then make web requests through it.
EDIT:
(for the "I really need this" crowd)
If you really want to modify your web server to send requests through a proxy, there are a few Go packages already written to help you. GoProxy is one such package.
I am serving content locally, accessible through http://0.0.0.0:4000. That works ok, I get a correct webpage, which contains the following line inside a script:
var socket = io('http://example.com');
i.e. I am referencing an external server. Now my browser shows the followoing error:
GET http://example.com:4000/socket.io/?EIO=3&transport=polling&t=1417447089410-1 net::ERR_CONNECTION_REFUSED
That is, the browser is trying to connect using the same port that it used to get the original page.
Everything works fine when both the SocketIO server and the web server listen on the same port.
Am I missing something? Is this a bug? Is there a workaround? Thank you.
You can read here about how a plain webSocket is initially set up. It all starts with a somewhat standard HTTP GET request, but one that has some special headers set:
GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
The interchange may also allow the host to enforce requests only from web pages on certain origins. While this header can be spoofed from non-web-browser agents (so the server has to be prepared for that), it will likely be correct when the OP is using a real browser (assuming no proxy is modifying it).
If the server accepts the incoming request, it will then return an HTTP response that looks something like this:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
At this point, the socket which used to be an HTTP socket is now a webSocket and both endpoints have agreed that they're going to use the webSocket data format from now on. This initial connection may be followed by some form of authentication or new or existing cookies can also be used in the authentication during the initial HTTP portion of the connection.
socket.io adds some enhancements on top of this by initially requesting a particular path of /socket.io and adding some parameters to the URL. This allows socket.io to negotiate whether it's going to use long polling or a webSocket so there are some exchanges between client/server with socket.io before the above webSocket is initialized.
So, back to your question. The socket.io server simply spies at all incoming web requests on the normal web port (and looks for both it's special path and for special headers to indicate a webSocket initiation rather than a classic HTTP request). So, it runs over the same port as the web server. This is done for a bunch of reasons, all of which provide convenience to the server and server infrastructure since they don't have to configure their network to accept anything other than the usual port 80 they were already accepting (or whatever port they were already using for web requests).
By default in socket.io, the domain and port will default to the same domain and port as the web page you are on. So, if you don't specify one or the other in your connect call, it will use the domain or port from the web page you are on. If you want to use both a different domain and port, then you must specify both of them.
Our web application has a button that is supposed to send data to a server on the local network that in turn prints something on a printer.
So far it was easy: The button triggered an AJAX POST request to http://printerserver/print.php with a token, that page connected to the web application to verify the token and get the data to print and then printed.
However, we are now delivering our web application via HTTPs (and I would rather not go back to HTTP for this) and newer versions of Chrome and Firefox don't make the request to the HTTP address anymore, they don't even send the request to check CORS headers.
Now, what is a modern alternative to the cross-protocol XHR? Do Websockets suffer from the same problem? (A Google search did not make clear what is the current state here.) Can I use TCP Sockets already? I would rather not switch to GET requests either, because the action is not idempotent and it might have practical implications with preloading and caching.
I can change the application on the printerserver in any way (so I could replace it with NodeJS or something) but I cannot change the users' browsers (to trust a self-signed certificate for printerserver for example).
You could store the print requests on the webserver in a queue and make the printserver periodically poll for requests to print.
If that isn't possible I would setup a tunnel or VPN between the webserver and printserver networks. That way you can make the print request from the webserver on the server-side instead of the client. If you use curl, there are flags to ignore invalid SSL certificates etc. (I still suspect it's nicer to introduce a queue anyway, so the print requests aren't blocking).
If the webserver can make an ssh connection to something on the network where the printserver is on, you could do something like: ssh params user#host some curl command here.
Third option I can think of, if printserver can bind to for example a subdomain of the webserver domain, like: print.somedomain.com, you may be able to make it trusted by the somedomain.com certificate, IIRC you have to create a CSR (Certificate Signing Request) from the printserver certificate, and sign it with the somedomain.com certificate. Perhaps it doesn't even need to be a subdomain for this per se, but maybe that's a requirement for the browser to do it client-side.
The easiest way is to add a route to the webapp that does nothing more than relay the request to the print server. So make your AJAX POST request to https://myapp.com/print, and the server-side code powering that makes a request to http://printerserver/print.php, with the exact same POST content it received itself. As #dnozay said, this is commonly called a reverse proxy. Yes, to do that you'll have to reconfigure your printserver to accept (authenticated) requests from the webserver.
Alternatively, you could switch the printserver to https and directly call it from the client.
Note that an insecure (http) web-socket connection on a secure (https) page probably won't work either. And for good reason: generally it's a bad idea to mislead people by making insecure connections from what appears to them to be a secure page.
The server hosting the https webapp can reverse proxy the print server,
but since the printer is local to the user, this may not work.
The print server should have the correct CORS headers
Access-Control-Allow-Origin: *
or:
Access-Control-Allow-Origin: https://www.example.com
However there are pitfalls with using the wildcard.
From what I understand from the question, printserver is not accessible from the web application so the reverse proxy solution won't work here.
You are restricted from making requests from the browser to the printserver by cross-origin-policy.
If wish to communicate with the printserver from an HTTPS page you will need the printserver to expose print.php as HTTPS too.
You could create a DNS A record as a subdomain of your web application that resolves to the internal address of your printserver.
With those steps in place you should be able to update your printserver page to respond with permissive CORS headers which the browser should then respect. I don't think the browser will even issue CORS requests across different protocol schemes (HTTPS vs HTTP) or to internal domains, without a TLD.