I work on embedded devices but am not able to install any software on them (e.g. programs like gdbserver are out). I need to monitor javascript events on those browsers. For example, if we run a web app on the EWB, the device it's on might have a keyboard pop-up. I need a way to see what triggers this event.
I am thinking along the lines of perhaps embedding something into the HTML or javascript that automatically reports any events back to a workstation somewhere.(I already have logs, but they are not live and it's difficult to pinpoint what happens - even beartailing them... wish I could have something like Firebug, but since it's embedded I can't)
Has anyone seen anything along those lines?
To get a debug connection to a web app or page running on a remote device:
Install vorlon using npm
Download ngrok
Start the vorlon server, the server port will probably be localhost:1337 and the following steps assume this
From a terminal/command prompt run ngrok with ngrok http 1337 and it should report an ip address for the other end of the tunnel, something like def01234.ngrok.io available via http and https.
Instead of the local script tag which vorlon suggests, use the remote ngrok address, e.g. <script src="https://def01234.ngrok.io/vorlon.js"></script>. ngrok exposes both http and https - as this is over the public internet I would strongly recommend using a secure connection.
Log onto the vorlon server on your local machine.
If the above test works you are going to want to do two more things:
Get an account at ngrok (or an alternative secure tunnel service) to get a fixed address.
Configure vorlon authentification according to the instructions on this page. By default it is insecure so ANYBODY with the exposed ngrok address could log onto the dashboard and mess with your embedded devices.
Related
I use p5.js in my school project and it does not work in Google Chrome(also Microsoft Edge, idk about Opera), with JavaScript activated, but only when its on hosting. When I got it on Localhost it works just fine. In Mozilla it works in both situations. Iam confused.
http://klauzury2c2021.8u.cz/
you can find all of the code on the site
It looks like you are are hitting this issue with the p5.Sound library that prevents it from working correctly when loaded over http. Since you're hosting your site on a public server the best solution would be to enable HTTPS for your server and have HTTP requests redirect to the HTTPS url. However if you are unable to do this you can make this work with an AudioWorklet polyfill. Just add the following line to the head of your html file:
<script src="https://unpkg.com/#free-side/audioworklet-polyfill/dist/audioworklet-polyfill.js" type="text/javascript"></script>
Updated ↑ Old Answer ↓
I originally misread your question and though you were specifically struggling with testing on localhost. Here are instructions for cases where you are testing with a local server:
Apparently people have had success working around the issue using a tool called ngrok. Which allows you to expose a local service via a public HTTPS endpoint. So if you're running a local HTTP server on port 3000 you would open a terminal and run ngrok http 3000 (having followed the basic installation and setup steps for ngrok). Nrok will assign you a public URL, which it will display in a message to the terminal like this:
Forwarding https://<UNIQUE_ID_HERE>.ngrok.io -> http://localhost:3000
Then instead of accessing your sketch page via http://localhost:3000/ you can access it via https://<UNIQUE_ID_HERE>.ngrok.io/ and that should work around this p5.sound issue.
I'm trying to create a web page that can connect to a client-local WebSocket server. The idea is to use the JavaScript client running in the browser as kind of a proxy to enable communication between the remote web server and the locally installed client application which implements the WebSocket service.
So basially, what I'd do is load a web page from https://example.com which includes some JavaScript that opens a new WebSocket to ws://localhost:1234/context.
This works fine as long as the web page is accessed via http. As soon as https is used, however, Firefox and Internet Explorer refuse to connect and the WebSocket constructor throws an exception (SecurityError, code 18).
Now, I already found advice from Mozilla stating that https sites should only use secure (wss://) WebSockets and plain http sites should only use plain WebSockets (link). But I don't really see the security issue when connecting to localhost from within an https context. Besides, this works like a charm for Chrome, Opera and Safari.
So the actual question is: Is there any way to work around this issue? Like introducing a non-https context inside the web page or something similar to get all browsers to connect to ws://localhost from within a https-delivered web page?
Thanks a lot in advance! I'm not exactly a web developer so this kind of browser-specific behaviour isn't really in my fields of expertise :)
You have to accept the cert first.
You can do this by simply going to https://localhost:1234/context, in your case. Once that's done, you can use the wss URL in your question.
I have an HTML project (CSS/JS/jQuery) that I'd like to test on an iPad (in Safari). From what I've read, iOS browsers don't support the file:///path/to/project protocol, and even if it did, I don't believe that you'd be able to navigate the file system to where your project is located.
Please correct me on any of this information if I'm wrong, I'm an Android guy so much of this is new to me. Nonetheless, I tried to use an app called Fileapp to solve my problem. I was able to access and load my project, but it was within Fileapp's native browser, and not Safari (unless it actually WAS Safari and it was just masked).
Does anybody know of a solution to my problem (preferably free)?
2016 UPDATE:
There are several services which now make this easy. If you don't have your own web server check out one of these free services which make updating a live webpage from your PC easy:
Heroku
Git Pages
Both of these services require using git, learn it, you won't regret it.
Days of FTPing or using Dropbox to serve html to an iPad are long gone.
If you need to be able to do this while not connected to the internet check out this article on using local IP tunneling. This would essentially open up the localhost on your PC to be viewed by anyone on a wifi network, regardless of if the wifi was actually connected to the Internet.
http://wesbos.com/localhost-mobile-device-testing/
I prefer Heroku as I am more likely to be switching between locations and PC's than I am to be on a wifi network without an Internet connection.
OLD ANSWER 2012
Get a Dropbox account and put the project in your public folder.
Right click to get the public link and then browse to that location on your iPad.
When I get link from the iPad app it doesn't work it just shows the raw html with a URL structure like so
dropbox.com/s/...
When I go to the website and copy public link (only available if the file is in PUBLIC FOLDER) I get the link that actually works.
Apache probably isn't the most convenient webserver to use for this kind of ad-hoc serving of a local project. Instead, if you're on Mac or on a Linux distribution that has Python installed (which is most of them), you can launch a webserver to serve your current working directory at the terminal with a one-liner:
python -m SimpleHTTPServer
By default it will serve on port 8000; you can specify another port by passing it as a final argument to the command.
To connect to this server from another device, like your iPad or phone, first of all you'll need to make sure your phone is connected to the same local network as your Mac or Linux PC. Then, on the computer, run
ifconfig
and look through the output for your local IP address, which will be labelled as inet addr in the output and listed under one of the connections other than "Local Loopback". On my current PC, I see inet addr:192.168.0.3 listed under the wlan0 connection.
Now, on your phone, open your browser of choice and navigate to the IP address you got from ifconfig on whatever port SimpleHTTPServer is serving on. For example, http://192.168.0.3:8000. You'll be presented with a directory listing corresponding to the directory in which you launched the server, and from there you can view whatever files you're interested in.
The answer to your question is that even with iPadOS the iPad is not a replacement for a Windows, Linux, or Mac. Still too many “can’t get there from here” cases.
One solution to the problem, as pointed out by minitech in the comments of the original questions, was to set up an apache server on my local network and connect directly to it. This worked exactly as I needed it to.
Is it possible to communicate with a desktop application from browser?
I want to do something like this,
Let's say there is a button in my web application with a URL to a data source and when button is clicked desktop application opens and get that data source URL and process data with desktop application.
Is it difficult to do such thing? Any examples?
On windows its trivial to create a custom URL Protocol that's invokable via
..
This works in IE, FF and Chrome, although in the latter the link must be opened via javascript to avoid omni-bar confusion.
You will need to have something running on the deskop, like a server, and make a request to it for the server to open up an application. You could do it with a Node.js. Of course that requires the server to be running on the client's desktop.
The alternative would be to make a browser extension / plugin, and have people install that. Those extensions could probably launch an application on the desktop.
You can easily add Fleck WebSocket server to your desktop application, and then access this using Websocket.
Note: Only Windows 8 and 10 support WebSockets through Microsoft's WebSockets implementation, but Fleck will work with Windows 7.
https://github.com/statianzo/Fleck
It's quite easy to add Fleck to your project using NuGet Package Manager:
Install-Package Fleck
Here is the echo example from Fleck webpage (add this to the C# program to execute during startup):
var server = new WebSocketServer("ws://127.0.0.1:8181");
server.Start(socket =>
{
socket.OnOpen = () => Console.WriteLine("Open!");
socket.OnClose = () => Console.WriteLine("Close!");
socket.OnMessage = message => socket.Send(message);
});
In the javascript:
var exampleSocket = new WebSocket("ws://127.0.0.1:8181", "protocolOne");
exampleSocket.send("Here's some text that the server is urgently awaiting!");
//and receive (make a listener for the socket) :
exampleSocket.onmessage = function (event) {
console.log(event.data);
}
Hm, you need something like client-server application. The server is a lightweight http server, which is waiting for messages from the client (browser). The browser can communicate with your server via ajax for example.
Here is a clunky suggestion, but I think worth mentioning all the options since the custom URI and running server solutions are pretty involved... Generate a small file containing the parameters of interest, with a custom extension associated with your desktop app. So when the user clicks the browser button they will have to go through the browser's file download dialog/toolbar and maybe some annoying security verification popups... not ideal user experience, but might be the easiest way to implement this type of communication, and doesn't require a process running in the background like a server.
I have a web app used within my company for interfacing to old databases and poorly organized files. I need a way to allow the users to open the actual files from the network and not download copies, so they can be edited in place. Considering a solution like this or the custom URI scheme so that a small executable not running in the background can simply be passed the filename and open it for the user directly.
the desktop application should embed a small server in it, like Jetty. Since the browser content source domain (e.g. www.myDomain.com) is different than the localhost domain of the Jetty, you would run into security problems. These should be overcome by the use of CORS (Cross Origin Resource Sharing) which is a new standard. Using CORS, the Jetty server tells the browser that it/localhost allows Cross domain access to its resources if the requests originate from the source domain www.myDomain.com. For security reasons, i would also make the Jetty reject any request whose source ip is not localhost
In addtion to Alex K's answer for windows... for those looking for solution on macOS and Linux.
Linux
Most of the modern distros implement freedesktop standards and one of them is desktop files. You can create a desktop file with [service]
section.
$ cat test.desktop
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Comment=My test app
Name=TestApp
Icon=TestIcon
Exec=/opt/test/test.sh %u
DBusActivatable=true
Categories=Network;
MimeType=x-scheme-handler/test; <------ This is handler for test://somedata URLs
NoDisplay=false
Copy this file in /usr/share/applications/test.desktop
macOS
Simply add something like following in your applications Info.plist file
<array>
<dict>
<key>CFBundleTypeIconFile</key>
<string>/tmp/test.png</string>
<key>CFBundleTypeRole</key>
<string>Viewer</string>
<key>CFBundleURLName</key>
<string>com.mytest</string>
<key>CFBundleURLSchemes</key>
<array>
<string>test</string> <---- This is handler for test://somedata URLs hit on browser
</array>
</dict>
</array>
We have a web application. There are physical devices that we need to be able to communicate with, and we have access to all of our clients computers to install whatever software we need. Now, for the question: Is there a way to make this browser-agnostic? As in, not requiring ActiveX controls?
One of my ideas was to install a custom made webserver on each client and then have javascript on our webpage that communicates with that webserver. This could be done by the same way that http://earlz.biz.tm javascript can access subdomains assigned to 127.0.0.1 such as http://loopback.earlz.biz.tm The problem with this of course is that the client's custom made webserver would be forced to run on port 80(which will have conflicts at least sometimes), or we would have to use a nonstandard port for our web application, which is quite undesirable.
Does anyone else have ideas on how to do this?
Just to clarify. Our clients will be using regular PCs with Windows. We need to communicate with physical devices through these PCs. One such thing is a signature pad. So we want for people to be able to sign the signature pad and it show up in the web page.
I don't think browser-based is the solution for this. There are too many security issues. You're better off writing a desktop application that incorporates some web functionality.
I think web servers and possibly comet is the way to go.
Web servers can run on any port you like, as long as there aren't any firewalls blocking the ports, or they are configured to allow http traffic to pass through on different ports. Although theres nothing wrong with just using port 80 either.
On the mini web server you will then need to interact with the device. You mention you are a .net shop, so you will probably have to install linux and apache + mono on these devices - not sure if this is feasible.
Sounds like a great project.
I would try to look at Java Applets...
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html
"JDK 1.1 signed applets can access local system resources if the local system is properly set up to allow it. See the JDK 1.1 Signed Applet Example page for details."