How does Javascript send udp broadcast on the LAN in chrome
I plan to make an application that send udp broadcast on the LAN. I wish all code are in html/js and it works on Windows and MacOS.
The work flow is - JS websocket connect to my wss server, run a chrome extension connect to wss server also. JS send wss packet to wss, and chrome extension get wss command, and chrome extension send udp broadcast on the LAN, get udp response, then send back to wss and web client.
Is that possible? or do you have better idea?
Related
I don't have a valid SSL certified server at the moment (please don't ask why) and I'm using Chrome and remote debugging to try to get my PWA to pass the lighthouse-PWA tests so I can get the "Would you like to install this APP" prompt.
The problem is my IIS Express server is self-certified which doesn't pass the criteria but everything is good until lighthouse tries to invoke the APP via http instead of httpS and then it just hangs 'cos as you know IIS Express listens for httpS on something like port localhost:12345 and http localhost:22222.
I have rewrite rules to redirect http to httpS but this seems to change the destination port before lighthouse sees it :-(
How to I fudge the test so I can debug my PWA on my USB connected phone with only a self-certified server?
UPDATE:
To clarify, lighthouse connects to the server https://localhost:12345 and does some performance and functionality tests before checking that all http requests are converted to httpS requests. The problem is it tries http://localhost:12345 and IIS Express isn't listening for http on that port. The request eventually times out and Lighthouse fails the test as it did not get a response.
I am trying to run a web on my local network that connects to the server through a websocket. When I test it from the same machine that is serving the web (localhost) it works fine but when I try to access the web from my android phone with chrome I get "net::ERR_CONNECTION_REFUSED". It seems that chrome refused all connections to localhost that are not certificated.
I have installed a self certification with the hope that using secure websockets and the certification it would work... Now I can access from localhost as https but I am unable to access from other devices without geting "This Connection is Untrusted"
There is any way to create a certified local network where I can browse to https://192.168.0.x (server IP) from other device and use websockets or secure websockets?
I am open to read other solutions where websockets work in a local network from an android browser.
I have a very curious issue with an application. When debugging locally, I can send emails just fine using a client's G Suite email credentials:
<smtp deliveryMethod="Network" from="client#customdomain.com">
<network defaultCredentials="false"
host="smtp.gmail.com"
port="587"
userName="client#customdomail.com"
password="supersecret"
enableSsl="true" />
</smtp>
Now, it's very important to note that the application will send just fine with the credentials when running on localhost using Visual Studio. However, when deploying to LIVE and using the exact same credentials, the application refuses to send and I only get the canned response back saying "Failure Sending mail".
I have enabled "less secure applications" in the settings and have verified the "suspicious activity" from the server's IP address. I can also log in to the Gmail account from the server using RDP and opening Firefox to go to Gmail.com.
No firewall rule has been set to block SMTP or anything on port 587.
UPDATE: the materialized error message is
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 74.125.192.108:587
74.125.192.108 being smtp.gmail.com's IP Address (or one of them, at least)
UPDATE 2: I can also not get Thunderbird on the remote server to send an email using the supplied credentials, however it can connect via IMAP and download the contents of the inbox just fine.
Well in this very specific case, it was the fault of the Amazon infrastructure this application ran on. Either amazon themselves, or the reseller changed a policy that ended up blocking communications on ports 465, 587 and 993 (and probably others too).
The "solution" was to nag them to sort it out.
Is it possible to communicate with UDP sockets via Chrome Extensions? I want to be able to have browser actions AND the ability to just send messages to UDP sockets.
No, it's not possible.
You either have to use both an app and an extension that communicate, or use an extension and a Native Host.
I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).
My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo.
I'm using Chrome 12.0 on Windows7.
I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.
However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.
Any ideas as to why this might be happening?
Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?
Many thanks,
-Dave
Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.
There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.
It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.
Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.
It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.