WebSocket to Ldap - javascript

I am trying to etablish a websocket connection to an ldap server. That I can simply send binary data to and receive binary data.
But it fails on the handshake whatever I do.
var socket = new WebSocket("ws://ads.de:PORT")
Yours sincerely
Skeec

Web sockets is a specific protocol, like HTTP, and it has "nothing" to do with a TCP/UPD socket.
You cannot connect with web-sockets to an LDAP-server, let alone connect to a different domain without receiving the appropriate CORS http-headers (and the browser supporting CORS).
You need to write a proxy WebSocket server application so that you can communicate with the LDAP-directory. You cannot do it in JavaScript (unless you want to use an ActiveX object, which will be incompatible with non-Microsoft browsers (and newer Microsoft browsers).
You better do it with plain-old AJAX with an asynchronous handler.
You don't need WebSockets for that, you're only wasting bandwidth.

Related

Validate WebSocket data

I have a WebSocket server written in javascript and send data to it from my CSharp application. Now how can I make sure that these are correct? I thought I could do something with hash values but I don't know how to do that. Does anyone have an idea or code example?
The first thing to understand is the types of WebSocket protocol/transports. WebSocket ws:// transport is basically unusable in terms of security as it uses HTTP. The wss:// protocol establishes a secure connection over TCP/HTTPS. The wss protocol, therefore, protects against man-in-the-middle attacks.
There is multiple methods to authenticate a user when setting up a WebSocket connection, and none are perfect. Since the standard WebSocket usage prevents additional headers from being set such as custom authentication headers, tried and true methods that would be used in a standard HTTPS request to verify the validity of a client can't be used.
The link here outlines some common methods to keep the client and server in sync while setting up a WebSocket connection, and still add some security so the server can keep track of what clients are opening WebSocket connections. There are a lot of workarounds listed for the server to safely receive sensitive, authentication data from the client.

connect to C# server from javascript

Is it possible to create a javascript program that connect to a simple C# server using a simple socket and not a WebSocket.
can you help me with a sample.
There is no standard way to make a TCP connection from Javascript code running in a web browser. (See the answer by #Johannes Hahn)
To communicate between your client and server, consider Microsoft's SignalR library. It is designed to allow a Javascript program, running in the browser, to communicate with a C# server. SignalR will use websockets; however, it will continue to work if websockets are not available by falling back to other transports. You can also specify transports, if you need to prevent it from attempting to use websockets.
SignalR connection starts as HTTP, and is then promoted to a WebSocket connection if it is available. WebSocket is the ideal transport for SignalR, since it makes the most efficient use of server memory, has the lowest latency, and has the most underlying features (such as full duplex communication between client and server), but it also has the most stringent requirements: WebSocket requires the server to be using Windows Server 2012 or Windows 8, and .NET Framework 4.5. If these requirements are not met, SignalR will attempt to use other transports to make its connections.
Also, be aware that if your Javascript is not running in a web browser, you can make regular network connections. For example, a Javascript application running on Node.js.
It seems that at least Firefox is supposed to know about socket, see https://developer.mozilla.org/en-US/docs/Web/API/TCP_Socket_API. But (taken from the same source) TCP or UDP sockets are not part of any standard and therefore likely either unsupported or completely different in other browsers.
In principle no. For security reasons browsers only allow a limited set of protocols. Chrome has a socket API, but that is not standard - https://developer.chrome.com/apps/sockets_tcp. There are solutions which use a WebSocket connection to a server which then establishes a TCP socket connection, e.g. https://github.com/kanaka/websockify, http://artemyankov.com/tcp-client-for-browsers/, so if you can't add WebSocket directly to the server you may want to check these out.

Maintain a backend connection on NodeJS across page requests?

I'm making connections via thrift (node-thrift) to a backend server to make api calls, but the communication is bidirectional (push/pull) to NodeJS.
While a user is browsing around different URLs, and Node is churning out jade templates and javascript files via Connect/Express routes, how do I maintain the connection to the backend server, and output (as an example) the connection status as part of the rendered jade output?
I have the connection object, but what do I do with it?
Sockets and port communication is generally a new area for me, so any help would be appreciated.
Keep in mind that backend server is not communicating to the web browser as the client, but rather the NodeJS server as the client.
(updated after discussion in comments)
So it looks like thrift is TCP-based which means the node client is going to keep the connection to your thrift API server open. This is entirely independent of what your node/express app server is doing with the browser clients. So if you keep a reference to your thrift client available to all requests, by attaching it to the app object for example, you should be able to determine it's current status and include that information in HTTP responses to the browser. There's not going to be any automatic coordination or association of any kind between your express app server handling browser HTTP requests and your thrift client making RPC calls to the API server. If you want coordination, you need to code that explicitly, but sending an HTTP response to a browser isn't going to automatically close your thrift TCP connection to the thrift RPC server (and same story vice versa).

HTML5 Server-Side Event: EventSource vs. wrapped WebSocket

Is the HTML5 Server-Sent Events (SSE) API just a restricted, event-based API on top of HTML5 WebSockets?
It seems to me that an EventSource is just a WebSocket that:
Cannot .send() data
Uses the text/event-stream format
Fires dynamically-named (server-defined) events instead of onmessage
The idea of the web server pushing events down to client devices is quite intriguing. Does this API have any traction?
I imagine the async event model would work beautiful when couple with Node, but not seeing a lot of use cases for this in my ASP.NET world.
Server Sent Events is useful in applications that only needs server push while Web Sockets are good for applications that needs fast communications in both directions.
Examples where Server Sent Events are a good solution are:
Stock Value changes
News feeds
Server Sent Events do some more things that is not built-in in Web Sockets, such as automatic reconnection and eventIDs.
Server Sent events also has broader web browser support as of today, with support in Safari (only support older drafts of Web Sockets) and Opera (has Web Sockets disabled by default, and uses an older draft).
Read more about Server Sent Events on Stream Updates with Server-Sent Events.
In addition to what Jonas said, the protocols are entirely different.
The WebSocket Protocol (RFC 6455) starts as an HTTP connection, then uses a handshake to upgrade the connection to the new protocol. This is a binary protocol that uses framing, message types, and more.
Server-Sent Events is a long running HTTP request that stays open. The server sends messages in a simple text-based format (UTF-8 encoding), delimited by \n\n. A message has fields event (the event type), data, id, and can optionally include comments.
One major difference is the security model. With WebSockets, the default is to let anyone connect. Rejecting a connection must be done on the server side, based on the Origin header.
SSE on the other hand, is closer to HTTP and uses same-origin policy. By default you can only make requests to the same host and port. In the future it will be possible to use CORS to make cross-domain SSE requests. As of today, browsers have not implemented this yet.
The two protocols take different approaches, as they solve different problems.

Using Javascript to connect with server using protocol other than HTTP

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.

Categories