I have a php websocket written as:
$socket = socket_create(AF_INET, SOCK_STREAM, 0);
socket_bind($socket, '127.0.0.1', 8080);
socket_listen($socket);
I run this by php server.php on command line and runs continuously. I am trying to send data from a javascript script to this server. Is it possible? Things I have tried is creating a websocket connection from javascript and using websocket.send(JSON) but it doesnt seem to register in the server.php (or im not sure how to correctly grab the data from the javascript send). Is it possible to send? If so, how could I send?
webSocket is a specific protocol running on top of TCP. It has a specific frame format that must be used in order to communicate with another endpoint using webSocket. It is not just a plain TCP socket as it looks like you are using. Here's a reference document on the webSocket protocol if you want to see how it works.
In fact, webSocket connections are initiated with an http request which are then "upgraded" to the webSocket protocol.
If you're using PHP, you can get a module that speaks the webSocket protocol and use that. I'm not a PHP developer myself, but I hear that Ratchet is a popular way to support webSockets with PHP and there are several others. Here's a related StackOverflow question on webSocket support for PHP.
You might be interested to this http://www.sanwebe.com/2013/05/chat-using-websocket-php-socket
Related
I would like to use some simple Javascript code I have written, with any public XMPP server using WebSockets. I have seen multiple examples of this and wrote my code accordingly. I am not using any javascript or XMPP libraries and would prefer to keep it that way.
I am opening my websocket with socket = new WebSocket("ws://xmpp.xyz"); and have tried over a dozen servers. My application does not need encryption and therefore doesn't use wss://.
The error returned in chrome's console is "WebSocket connection to 'ws://xmpp.xyz/' failed:". I have been able to successfully open a websocket to the external echo server echo.websocket.events/.ws. Using chrome's network inspect, I see the socket open successfully and my stanza's being sent and received correctly with callback functions.
I now wonder if all the examples I had read, were for servers being hosted in a company network, and none of the public XMPP servers will accept my websocket connection request. If they can accept my request is there something else I need in my url? Based on some of the examples, I have tried a few ports like 80, 5280 and some additions to my url (such as "ws://jabber.org:80/ws/").
Yes, at least one public XMPP server, Tigase.im, does support websockets.
After some light digging though the strophe.js code, I found a second parameter that specified the service as a string. Opening the websocket in pure javascript with the port provided by Wojtek and the protocol string set to xmpp worked.
socket = new WebSocket("wss://tigase.im:5291/","xmpp");
since I am learning node.js I was wondering about something:
When I use node.js server to run a websocket, so that clients can connect (like on a website via javascript), it always listens public. Isn't that a security problem, that everyone in the world would be able to send data to the ip:port. They just have to connect to the server via the data that are written anyway within javascript and send / receive data?
I was thinking about a token, which would make sense in Java or Swift etc, but in javascript it can be seen anyway?!
TL;DR: yes, It's totally secure.
Every time the browser sends an HTTP request, there is a port waiting for the server's response. The difference between this to an open port is that an open port is open for everyone on the web. In an HTTP request or web socket, the port opens only to the server.
To use socket.io on the client side, usually we start a node.js server and go like this:
<script src="/socket.io/socket.io.js"></script>
or with specific port:
<script src="http://localhost:3700/socket.io/socket.io.js"></script>
Question is:
is it necessary to use node.js server to serve socket.io.js ?
...or is it possible to
make a local copy of socket.io.js instead of goes to server every single time we need socket.io?
like, we go to view source and copy everything we got from the source of script tag,
paste and save it as socket.io-local.js so that next time we use:
<script src="socket.io-local.js"></script>
will that work ?
Updates
Thanks for everyone's great response,
I'm asking this because in the case I'm involved, I don't actually have access to the server:
I am writing the client-side to connect to other developer's Socket Sever which is written in Java.
Therefore I'll have to think a way to work around the fact that I don't have a server there for me.
from what I've been testing,
this way seems to work but I really don't know what's happening behind the scene.
You obviously can host the socket.io client library anywhere and pull it in to a page. However, it will almost certainly not work with your Java-based server.
To understand why, you need to understand what socket.io is really doing behind the scenes; the client library is only a small part of it.
Socket.io actually defines and implements its own protocol for realtime communication between a browser and a server. It does so in a way that supports multiple transports: if—for example—a user's browser or proxy doesn't support WebSockets, it can fall back to long polling.
What the socket.io client actually does is:
Makes a XHR GET request for /socket.io/1. The server responds with a session ID, configured timeouts, and supported transports.
The client chooses the best transport that the user browser supports. In modern browsers, it will use WebSockets.
If WebSockets are supported, it creates a new WebSocket to initiate a WebSocket connection (HTTP GET with Upgrade: websocket header) to a special URL – /socket.io/1/websocket/<session id>.
If WebSockets aren't supported by the browser or fail to connect (there are lots of intermediaries in the wild like proxies, filters, network security devices, and so forth that don't support WebSocket requests), the library falls back to XHR long polling, and makes a XHR request to /socket.io/1/xhr-polling/<sesion id>. The server does not respond to the request until a new message is available or a timeout is reached, at which point the client repeats the XHR request.
Socket.io's server component handles the other end of that mess. It handles all the URLs under /socket.io/, setting up sessions, parsing WebSocket upgrades, actually sending messages, and a bunch of other bookkeeping.
Without all of the services provided by the socket.io server, the client library is pretty useless. It will just make a XHR request to a URL that doesn't exist on your server.
My guess is that your Java-based server just implements the WebSockets protocol. You can connect directly to it using the browser-provided WebSocket APIs.
It is possible that your server does implement the socket.io protocol – there are a few abandoned Java projects to do that – but that's unlikely. Talk with the developer of your server to find out exactly how he's implemented a "socket server."
A standalone build of socket.io-client is exposed automatically by the socket.io server as /socket.io/socket.io.js. Alternatively you can serve the file socket.io-client.js found at the root of this repository.
https://github.com/LearnBoost/socket.io-client
I have a module called shotgun-client that actually wraps socket.io. I needed to serve a custom client script as well as the socket.io client script, but I didn't want every user of my module to have to include multiple script references on their pages.
I found that, when installed, you can serve the generated client script from socket.io by reading the file /node_modules/socket.io/node_modules/socket.io-client/dist/socket.io.js. So my module adds a listener for its own URL and when it serves my custom client script it also serves the socket.io client script with it. Viola! Only a single script reference for the users of my module :)
While this is technically possible, I don't see why you'd need to do that. If you're concerned about reducing the data that goes over the wire, this change won't actually do much beyond the few characters saved in the shorter src tag. Simply changing the location of the JS file on the server won't actually improve performance - the JS has to be sent.
Proper caching (which Socket.IO has) will return a 304 Not Modified (and not re-send the JS file every time you load a page).
I know there is an implementation of VNC using WebSockets (http://novnc.com) but that still requires a server. I am looking to create a simple client-side JavaScript only (no Flash) connection to a port running SSH. I am guessing WebSockets is the only way to go since it does TCP. Any example code? Any other way?
Sorry, given your constraints (client-side Javascript only), there is no way to connect to a plain old SSH server.
WebSockets is not plain TCP. It's a framed protocol with a HTTP-like handshake between the client and server that includes origin policy.
Flash can make plain TCP connections, but it also has origin policy enforcement. The way it does this is by making a connection to the same server on port 843 and asking for a special XML file that contains the origin policy.
If you are willing to relax your constraints slightly such that you are willing to run a generic WebSockets to TCP proxy either on a server (any server) or on the client then you can do what you are wanting to do. noVNC includes a C and python WebSockets to TCP proxy: http://github.com/kanaka/noVNC/tree/master/utils/.
Other info you might find useful:
Current WebSocket draft: https://datatracker.ietf.org/doc/html/draft-hixie-thewebsocketprotocol-76
Simple (insecure) way of running a flash policy server (Linux/UNIX with socat) is described here: http://github.com/kanaka/noVNC/blob/master/docs/flash_policy.txt
More info about the flash policy file: http://code.google.com/p/doctype/wiki/ArticleFlashSecurity
You can take a look at serfish. It's a solution to access a SSH server. But if you're hosting your web application on the same server as your ssh, there are other solutions such as shell in a box.
For those still searching, paramikojs could be the answer.
I'm currently having a similar issue:I need a SSH JS client-side implementation, and I need it to be BSD licensed. Alas paramikojs seems to be GPL licensed.
It's definitely possible using a Linux emulator with full network support like the great OpenRISC emulator jor1k.
Note that I've created browser-tools.net, a collection of in-browser tools from number of different projects.
Yes you can
Install SSH server on your server
Write a server side program (could be in PHP) that uses SSH
client in the background
Redirect messages between the SSH client (that probably has been residing in the same server as SSH server) and the JavaScript program in the web browser other side of the internet.
That server side program acts like a postman only and the java script program in the browser is just another postman between the user and server program.
(SSH server)<->(SSH client)<->(PHP e.g)<->(JavaScript)
Also don't forget that in the JavaScript program could have use Ajax for better mechanism. Also SSH client might be not completely and absolutely necessary because that PHP server side program could directly connect to SSH server
Can Javascript be used to connect with a server with a protocol other than HTTP or FILE? Ideally, I would like to connect to an SMTP server using Javascript.
Not possible due to security constraints in the browser. Can be done in flash or java as far as I know. The upcoming WebSockets won't help you either.
Your best option is probably to call a script on your server which makes the socket connections to the final destination, i.e the SMTP server and then passes data back to the client over HTTP.
You do not have socket access with browser-integrated JavaScript, it would violate the sandbox security model. So no, no SMTP, or any other protocol. Even file:// should be rather difficult.
Server based JavaScript like node.js can do things like this.
Accessing e.g. SMTP via the browser is usually done through a proxy script that runs on the server and speaks HTTP to the client.