Is it possible to forward locally-server site (but served with https) via remote debugging somehow?
My site is served via https because it uses some also https-based API. But it seems like there is no option now to forward it straightly.
It seems to work. If you forward port 1234 to localhost:8080, then you should be able to access https://localhost:1234 on your device.
There's no spot to specify a protocol because it's a straight port forward.
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.
So I am trying to build a C Program that handles HTTP requests through a web browser. The program is listening on a predefined port for incoming HTTP requests and responds appropriately. It is working totally fine when I place is it in the root directory but it doesnt work when I move it to directory on its own.
For instance, this works:
localhost:9000
but this doesnt:
localhost:9000/myprogram
Any clues on how I may fix this?
Hard to answer with so few details. But to get started I would check the following:
What does the web server log say?
Is the web server configured to allow execution of [CGI] in this directory?
Are you sure you haven't mixed up the web root with the directory root, thus placing your
program in the wrong place?
Are the directory and program access modes set correctly?
I have a website running on a NAS server and I also have a ip camera on my network. I can configure port forwarding on my router to forward http requests to either my nas website (192.168.1.64) or ip camera (192.168.1.200) from the internet. I have configured both independently and was able to access from internet. However, I only have one IP address so I have configured port forwarding on my router to forward http requests ( port 80) to the web site on my NAS where I have provided a hyperlink on the default html page to the IP camera (href=http://192.168.1.200/....html). From home the link works because the internet browser is running on a computer on my network. But browsing from a computer ouside of my router ( the internet) the link does not work. The browser is attempting to communicate with ip address 192.168.1.200 which do not exist on the internet. How can I link to the ip camera website from a html page on my NAS website behind the router. I hope I have explained this in enough detail for you to understand.
You can't, plain and simple. This is because you can never get your browser to connect the device that does not have the port forward directly, therefore you can never load a page directly from that device to your browser, however you try and work it.
When I refer to "the other device" in this is answer, I am referring to whichever one does NOT have the port opened through the router to it.
Setting aside the security problems you are creating by doing this that frankly, horrify me, you have two options:
Set up a port redirect on your router to the other device, so that a different public port is redirected to port 80 internally. This would mean you could access both devices directly across the internet. Not all routers support this (albeit fairly basic) functionality.
Set up some form of proxy script that will fetch the page from the other device and display it on a page (in an iframe maybe?) on the device that does have a port forward. This will probably require a third web server inside your network, since it is unlikely either the NAS or the camera will support any form of scripting language.
I do not recommend either of these options, but that is what you are left with.
You are creating a huge hole in your network security by doing this. Only do it if you 100% trust the fact the neither device could under any circumstances be hacked into. Are you that confident in some software you didn't write - or even some you did?
Sorry for the subject line sounding like an even nerdier Harry Potter title.
I'm trying to use AS3's Socket class to write a simple FTP program to export as an AIR app in Flex Builder 3. I'm using an FTP server on my local network to test the program. I can successfully connect to the server (the easy part) but I can't send any commands. I'm pretty sure that you have to use the ByteArray class to send these commands but there's some crucial piece of information that I'm missing apparently. Does anyone know how to do this? Thanks!
Dave
The FTP protocol predates UTF encoding. Switch to ANSI/ASCII for better results. If you do opt for writeMultiByte instead of writeUTFBytes, be aware that it is buggy in linux. Here's one way around it.
There's another question here where the line ending turns out to be the culprit, so make sure that you get it right (as suggested above).
As said before, if this is running from the web, all socket connections will require a crossdomain policy, but this is NOT file based over HTTP. Recent changes to the security rules mean that any socket based connection must first get a crossdomain from a policy server hosted on port 843 of the target host.
Quoting from Adobe:
A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.
HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.
Essentially, what this means is that you must be in control of the target FTP host, and install supplementary software on it to get this working.
Read this link too and maybe it can be useful this one too.
The first one is about policy files and the second is an example of a TELNET (so, no FTP here) client.
I've been able to get an FTP client working in a browser, but it's buggy. I had to get a listener running on port 843 to server the policy file so that Flash would be allowed to connect and transfer data. Then, I had to figure out how FTP actually works:
You have to open 2 sockets: a command socket and a data socket. The command socket is where you send your USER, PASS, CWD, and STOR commands. The data socket is where you write your ByteArray data to. Sending the PASV command will tell you what port your data socket must connect to.
Where it is buggy is on Mac, in both Safari and FF, when I call the "socket.close()" command, the server socket actually closes. On Windoze, it does not. This is a huge problem because the Event.CLOSE event is not fired until the SERVER closes the connection. This is in the livedocs.
This is where I'm at. I have no idea why it would work flawlessly on Mac and then be completely busted in 3 different browsers on Windows. The only thing I can come up with is that it's either something in my Windows configuration that's preventing proper communication with the server, or it's the Window Flash player that's causing the problem.
Any thoughts?
We will need more info to resolve this.. What you're saying here appears correct to me. You're using the Socket class to send data though, not ByteArray.
Are you sure data is not being sent? How are you receiving the response? It may be that it's working fine but you're just not aware of it? As i said, tell us more about what you're doing..
Lee Brimelow has a screencast on gotoAndLearn of writing an POP3 client. It's essentially the same of what you're doing so take a look.
Are you 100% sure the syntax is correct? I know with HTTP you'll have to an include extra linebreak after the request for it to go through. Without it you'll get nothing back. Not sure how it is with FTP though.
The FTP standard requires CRLF at the end of commands. Try using "\r\n" in place of the "\n" in your example.
You must serve the CrossDomain Policy File from your FTP server in order to conect correctly.
From what I've gathered, you have to send each command one at a time and validate the response before moving on. You should be getting something back against ProgressEvent.SOCKET_DATA
Try just this and see what you get in response.
socket.writeUTFBytes("USER "+user+"\n"); socket.flush();
You would then read the response out like this.
var response:String = mySocket.readUTFBytes(mySocket.bytesAvailable);