I have an intranet site, so i'm not worried about security. What I need to do is allow my users to launch putty.exe from a browser link. The point is that there are numerous putty connections on different ip's ports etc.
Currently we use IE and activex. But we want to use chrome or firefox.
I've heard of ie tab and locallink, but they're not that feasible.
Is there a way to launch a program from a link, crossbrowser?
ie Putty
Being that the program you want to use is PuTTY, in you could do something like:
Putty
Which in Chrome and Firefox will prompt you to choose the appropiate program for that protocol the first time, after that the program should start automatically...
You could also use ssh or ssh2 instead of telnet if your client software (in this case PuTTY) has those URI schemes registered....
Related
I am developing a webpage that uses camera. When I test in Chrome in my local network, camera doesn't work and I get warning in the console:
getUserMedia() no longer works on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See link for more details.
In the link provided there is an instruction to set some flags in Chrome. So I tried. My command looks like this:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --unsafely-treat-insecure-origin-as-secure="192.168.0.15" --user-data-dir=c:\chrome-dev-profile
But when I run Chrome I get this message:
You are using an unsupported command-line flag: --unsafely-treat-insecure-origin-as-secure. Stability and security will suffer.
What am I doing wrong?
Is there another way I can test in local network without setting up https server? I need this just for development.
Luka,
I've run into this bug just yesterday. I have not found out how to get Chrome to honor that flag on the command line yet. But I did find a workaround that works for my case.
I'm running my web services on a Linux machine that is running an ssh server. I'm testing on windows with chrome, and used putty to connect to the linux box from windows and then created a "local port forward" to make my remote linux box's ipaddress:port appear on localhost:port on windows. Depending on your platform this workaround may work for you. This approach isn't too cumbersome if you only have a few ports to forward.
In my particular case my setting for putty looked like
L8080 localhost:8080
To see more about port forwarding and ssh see: https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding
I sort of make shift followed this guide on how to setup remote debugging. Since I am using Adobe Animate to compile my app I assume it has done the majority of the build steps already as I get a similar screen described.
I don't understand though. Here I have port forwarding up on my router so that it goes to my PC. I have TCP port 7935 up and open. Windows firewall on or off doesn't seem to make difference. Windows firewall even prompted me to allow or deny fdb after I ran it. I can't get my phone to connect via remote debugging. I want to be able to send this to my client who is having issue with the app so I can see what's going on under the hood instead of relying on a giant sum of try/catch statements and screenshots. Any help?
I tried a dummy domain and it seems to know that it can't connect to it. When I try mine or my IPv4 it doesn't let me connect. It just freezes up the app.
I don't know whether it works or not in Animate CC, but it works via Flash Builder. I'm using Android real device and I have Android SDK tools installed on my PC
Yes, I have followed that tuts from official Adobe docs, but that doesn't work
First: Simply connect your device to your PC
Actually , you can debug your app remotely as long as your device has been connected with your PC. This step, doesn't necessarily requires FDB.
In my case , all I need was things like
adb connect 192.168.xx.xx:port
this will connect your Android device with your PC on your default network .
Second, set debug setting over network
You've done it in Animate CC, with addition you might want to check "install application on the connected device'
Third, just debug as usual
You can get all those debugging stuff including traces
Is it that all protocols implemented on top of TCP/ UDP are supported by chrome? Does HTTP/ HTTPS implementation somehow hides functioning SMTP or FTP in the background ?
Do all browsers support ssh through them or is it a design thing?
In terms of what protocols you can use in the Chrome browser bar you can use: HTTP, HTTPS, FILE, and FTP. SSH is not implemented by Chrome, but rather it implements SSL. It also does not implement SMTP, but rather when you visit a website like Gmail or Yahoo mail, you are simply visiting a website (via HTTP or hopefully HTTPS). That website is not at all connecting to an SMTP server to display your emails, but is merely serving up web pages and connecting to API's to display/edit/compose your email (by then which the email client's backend is connected to their SMTP server).
Also chrome does implement FTP, like you can visit an IP address that has FTP enable such as : ftp://123.34.45.890 and you can use the directory listings as a webpage. An example of this would the CentOS mirrors here. On the right column they have FTP sites. You can access the FTP director via web browser that supports FTP or you can fire up a terminal and do ftp ftp://ftp.is.co.za/mirror/centos/.
For the ssh part,Google chrome supports SSL and not ssh. Though ssh can be done using extensions like secure-shell. These extensions combines the ssh command (see http://openssh.org/ for details) ported to NativeClient with the “hterm” terminal emulator to provide a secure shell client for the Chrome browser.
Though a key thing to be noted is that “HTML Terminal”, or hterm, is an xterm-compatible terminal emulator written entirely in JavaScript.
It is intended to be fast enough and correct enough to compete with native terminals such as xterm, gnome-terminal, konsole and Terminal.app.
hterm is only a terminal emulator. It does not provide SSH access (or any other text-based command) on its own.
The 4 main protocols are HTTP, HTTPS, FILE, FTP. All other protocols are designed to work on top of them.
For the second part, all browsers can be made to support ssh through them.
I need to convert a web page requiring viewing a X window from using the VncViewer applet to some HTML5 based VNC client. The worry is NSAPI will get desupported in the near future on browsers (mainly Chrome) that disables applet functions.
I looked at noVNC and websockify and got it to work. But, here is my problem: We still have some client on IE8 that does not support Canvas. For those clients which has Java enabled and won't be changing to a higher version of IE or Chrome, we still want them to keep running the applet version. By running websockify in the wrap mode, it seems I can no longer directly connect to the VNC server (not through websockify) to keep those applet clients functional.
e.g. My command to run websockify is:
run 5903 --wrap-mode=ignore -- vncserver -geometry 1024x768 :3
After this, I tried to use the regular VNCViewer client to connect to port 5903, and it's rejected. Only the websockified page can view the VNC window. If I change the 5903 to 5902, then I can use the regular VNCViewer client to view window at 5903, however the websockified page can't view it at 5902.
Is there a hope to keep concurrent connection to my VNC server available (websockify and regular connections)?
Thank!
I would recommend starting your VNC server normally (not using websockify wrap mode). Then run websockify normally to target the VNC port. The Java client should continue to target the regular VNC port. The noVNC client should connect to the websockify listen port (which will then connect to the VNC server target).
The problem with wrap mode is that the original port is "hidden" (moved to a random high port and accessible to localhost only) and only the websocket port is exposed. But you still need the regular VNC port to be accessible for the Java client.
I run two desktop machines (m/kb using Input Director, etc). I would like to run Chrome's dev tools on my second desktop, yet run Chrome on my primary.
I know that Chrome offers remote dev tools for Android, but I am unaware (and unable to find) of any way to do this across PC's.
Is there a way to run Chrome dev tools remotely on PC?
That is actually quite easy.
Step 1 :
Make sure to launch the Chrome instance hosting the page you want to inspect (in your case the primary host) with the following additional parameter :
--remote-debugging-port=9222
Step 2 :
If the Chrome instance where you would like to have your Developer Tools front-end was on the same machine, you would then just have to visit the following url to get a list of the inspectable page :
http://localhost:9222
Though, as you want to run the front-end on a different computer, you should target your primary hostname or ip. But because remote debugging works only in a context of local instances (thanks Rob W for pointing this out) you have to, for example, make a tunnel between the port 9222 on your primary computer and another port local to the latter. See this question.