I am trying to get into the web push technology so I started looking around. I have basically found 2 technologies, that is Websockets and SSE. After ruling out Websockets because of lack of perl support, I wanted to try out the more native SSE-approach.
Now, trying to get SSE to work is a real pain in the arse. Every documentation has conflicting information and there does not seem to be a general consensus on how SSE works. Some say hat you need an <event-listen src="events.pm"> tag, others say you only need an EventSource JS object. Even with the EventSource object, I found around 4 possible implementations and none of them seem to work.
Here is what I have. I have an events.pm, which uses mod-perl. If you call that file, it returns data: I haz a websocket. That is sent with the content-type application/x-dom-event-stream.
The HTML and JS files have been rewritten so often with different implementations that I have given up on them. Can you guys please give me a working example?
Also: I do not understand how you can send specific messages to the client. Sending a predefined message seems to be fine. However, if I imagine a situation where someone sends me a message, I do not understand how exactly that information ('there is a new message for you') is transmitted to that exact browser that needs that information. Every post I found on this is vague at best.
EDIT
Basically, what I need is a way to say 'hey, are you allowed to get this notification? show me your id/session/token first!' on a per connected client basis. I wonder if it is at all possible with SSE.
I would say that Server-sent events are described pretty good in Stream Updates with Server-Sent Events article, namely the Event Stream Format. With Firefox 6 SSEs are now supported by majority of modern browsers (unfortunately except IE).
I do not understand how you can send specific messages to the client.
Sending a predefined message seems to be fine. However, if I imagine a
situation where someone sends me a message, I do not understand how
exactly that information ('there is a new message for you') is
transmitted to that exact browser that needs that information.
Clients are connected with the SSE server by keep-alive event stream, uni-directional connection which isn't closed until browser/tab is closed, user invokes close method or network connection is lost.
Basically, what I need is a way to say 'hey, are you allowed to get
this notification? show me your id/session/token first!' on a per
connected client basis. I wonder if it is at all possible with SSE.
This kind of authentication logic would be required to do on the server side, so it's dependent on the language or platform you are using. Unless there is library for that in your environment you would probably have to write it.
The spec has changed/evolved. Current version uses EventSource object. The HTML element is gone.
The current MIME type is text/event-stream. The x-dom-event-stream was used only in early implementations (Opera in 2006).
To identify/authenticate clients you can either use cookies or connect to an event stream URL that includes some kind of authentication token (session ID), and then you'll know that a particular TCP/IP connection is associated with that user.
http://html5doctor.com/server-sent-events/
Adding to #porneL's answer; you can tell EventSource to include cookies to the request it sends. Just create the EventSource object like this:
var evtsrc = new EventSource('./url_of/event_stream/',{withCredentials:true});
I tested this with latest version of chrome and firefox.
Source: http://www.sitepoint.com/server-sent-events/
edit: apparently this is not necessary / useless. See #Tamlyn's comment.
Related
I have a SignalR chat site that's meant for a school project (also uses C#). Theoretically, it is for trusted users, but as everyone will attest - never trust your users. This was proven to me as I sent out the link to a couple of my friends and they immediately tried to break it, ha ha.
I've sanitized all inputs properly now, but one thing that they were still able to do was to use the browser console tools to manually call the functions needed to send messages, etc..
Example: $.connection.chatHub.server.sendMessageToAll('FakeUser','FakeMsg',0);
I would like to prevent these types of actions. I recall a while back Facebook actually disabled the console window for "security" purposes. I even found several{1} resources{2}, which detail how this was done and attempts to further prevent console use once Chrome had fixed this.
However, none of these options work anymore and because browsers are constantly in flux, I'd rather not attempt to block at this level.
I was wondering if anyone on Stack knows of a better way to prevent these types of attacks? Is there a good way to check where the call is coming from? Does SignalR have a good method to prevent this? Ideas/Discussion would be surely welcome.
Trying to lock down the client like that might work reasonably well to prevent non-technical users from messing with your app, but it will do next to nothing against a knowledgeable and resourceful opponent. The circumstances under which such security measures make sense are rather limited, and certainly do not include any application that is accessible to everyone from the internet.
The only safe approach is well-known and very simple: the server does not trust the client for anything. It doesn't then matter what the client attempts to do as the server will refuse all actions it does not deem valid.
In your example, the server would assign a randomized opaque connection id to each session. The client would only be able to convince the server to do anything if they sent a valid id as part of their request; then, the server would not need to trust the client for a username because it would already know what connection each user has logged in from and could produce the username when given the id.
I'm setting up a stock-ticker like web-page, written in JavaScript. I am also writing the server that the page talks to, in C++.
I would like to make the web page efficient, such that it makes sends single subscription message to the app server, and then holds a keep-alive connection open, constantly receiving inbound data pushed from the app server.
At the moment, I have to re-issue the web clients' subscription call every time I receive data from the server. The problem is that each time the XHR object hits readyState(4), the call is effectively completed. Any data arriving at the web page after this is ignored. The web-client can resend data and that resets the object, but the send is unnecessary, and is only being used to reset the XHR object.
I would like to know if it is possible to somehow reset the existing XHR object, and put it into a state where it expects more inbound data, so that when more data is pushed to the web page, the web page responds and processes it.
Thanks in advance for any help you can give. Note: Not using JQuery on this project.
I highly recommend looking into Websockets, especially a library like socket.io, which encapsulates various browser's implementations of Websocket transports into a single API (WS, JSON, JSONP, Flash and Long Polling).
Socket.io client libraries should be now be supported by all major browsers. Your only challenge might be locating a C++ specific server implementation. Hopefully this SO question might be of some help
Otherwise, your only other option is long-polling or comet on the client with a suitable server-side implementation that would scale (i.e. something like an event driven server like NginX as opposed to a thread-per-connection architecture.)
I do appreciate that you are committed to C++ but my humble advise would be to investigate Node.js as it can and does provide a very performant solution with very little effort.
HTH and all the best.
HTTP is a one-off protocol: one request, one response, and you're done. If you want to keep a connection open, you can use Websockets (MDN reference page, client-side code example). However consider it won't be supported on older browsers (IE, for example, just started supporting Websockets on version 10), so you'll probably need to implement a fallback using XHR and long-polling.
I am working on a real time tracking application that uses Node.js and Socket.IO. In my tracking code that goes on a target site I have some code that grabs the user agent string of the browser and sends it back to the server. This USUALLY works fine but there are a few times where this data is set to undefined (this is where it happens).
For now, I just have a huge try/catch block on the server so it doesn't crash when running a method I've defined to detect what browser it is (it crashes when it tries to run the match() method). I'm assuming this is happening either from bots or from some other browser that has no user agent or has been tampered with. Am I wrong on that? Are there other reasons?
Does Socket.IO provide anything for browser detection? Either way I know I need to make the browser detection feature more robust but I'm just getting this project off the ground.
If there's no better way to do this, am I better off just checking to see if the data that was sent to the server is undefined and consider it as an "Other" browser?
See the difference in total connections and total browser numbers? At the moment, there's a difference of a little over 100. If this browser tracking issue wasn't happening the numbers should be exactly the same (because EVERY connection would have a browser, resolution, operating system, and a URL).
I'm not very familiar with socket.io, but it looks like you can get the request headers in socket.handshake.headers (Socket.io's Wiki – Authorizing). I don't know which browsers run JavaScript but don't have navigator.userAgent set, but maybe they'll send the User-Agent HTTP Header?
This actually had nothing to do with bots or tampered data like I thought it did. My problem was due to a rare race condition where the client would connect to the server but disconnect before sending the data to the server (the "beacon" event I have set up is where the client sends the data and the server receives it). So when the client went to disconnect, my server would look up the client but would return a undefined result because the data was never sent and stored in the first place. A rewarding experience but what a pain!
I found an interesting library that allows DOM manipulation from the server, this allows much of the logic to be hidden from the browser, so all the browser gets to see is what happens when you check the box, it does not actually know what to do when you check the box.
Seeing that it responds so quickly, I took a look at the network activity, and found an item with HTTP 101 (switching protocols) and it says the connection is still open.
It seems there is a way in JavaScript to receive streaming data.
How can this be? The code is somewhat large and the googling I did indicated it would be called Comet, but there is much more information about the highly cross-browser "long polling", but that does not seem to be what is happening.
What is a (simple) example for how to achieve fast results like this?
The HTTP/1.1 101 response header is the Websocket protocol handshake.
I have found socket.io to be the best ready rolled library (both client and server), especially when working with JavaScript. Socket.io will drop to flash sockets if possible then last resort long polling in older browsers that do not support Websockets.
Long Polling is a push technology. Before web sockets(HTML 5), the web suffered from class client server problem. The server can not push until client requests. So it was not possible to push data to clients. Long Polling is one of the way to do it.
It works in the simple way. The client would make a request to server, the server if has anything new to server would serve immediately or would wait till new content comes. When ever a new content comes, the server would send the response. On receiving the response, the client would again re-issue a request to the server. There are other ways of implementing Push Technology. Read this : wiki
I have to program websites, but I rather don't like the static HTML nature. I prefer more of a client-server architecture.
Now I've figured, that with XMLhttp, you can basically dynamically update your page and send/request for information/action to/from a server. So this would basically cover the client area.
But to complete a client-server architecture, it is necessary for the server to send/request information, too, without being queried.
Is there any way, for example for a chat server, to send back a received message to all clients (the clients use a web browser) without that the clients have to query in a fixed interval? I want to implement that one can see while you type something in.
There are several different ways to accomplish this. Some of them are already answered here, but I wanted to include a few more as well as my thoughts on them.
1. Polling
Frequent requests are made to the server to check for new info. This is the worst way to do this, but probably the easiest. If your site will have a low number of users, it might be worth doing it this way.
This can be accomplished by using setInterval(myFunction, n) in javascript to send XMLHttpRequests to the server every n milliseconds. Then, on the server, you respond to this with your new info, when you have it, or some message that implies no new info.
2. Long Polling
When the page is loaded, it makes a request to the server for new info. The server holds the connection open until there is something to send back. This method reduces the amount of network traffic used, but increases the resources used on the server. You can use this for a small number of users, but it doesn't scale very well.
The easiest way to do this is to have the page that handles the AJAX request simply wait for new information to be available, then respond. This can tie up a lot connections on your server. So, use with care.
3. COMET
COMET is basically long polling, but the server is setup properly for it. It knows that these connections aren't "real" and it uses less resources to handle them. This is a great solution for this problem, but it requires that the server is explicitly setup for this purpose. There are COMET servers and COMET addins for other popular servers, but it will require some setup and sometimes some money.
Implementing this on .NET isn't the easiest thing in the world. You can pay for solutions, try to find someone else's code that does something similar, or try to write it yourself. I've not found any decent free solutions for this. If someone else has, please comment.
4. RIA
Another solution would be to include Flash, Silverlight, or Java Applet on your page. People often do this by using a 1x1 object so that they can use Flash or Silverlight to talk to the server. If you don't mind adding the dependency, this is a decent solution. If you already know Silverlight or Flash, it could be relatively simple to implement.
You can find tutorials on the internet for each of these options.
5. Web Sockets
If you are on the cutting edge, you can look into Web Sockets. It's only available in the latest builds of modern browsers. It was part of HTML5, but it might be its own spec now. Regardless, it means that older browsers won't be able to handle it. But, if you don't mind limiting yourself to the latest of browsers, you can use this amazing feature.
I believe that Chromium is the only browser that currently supports it. However, there is work being done to implement this in Firefox and WebKit.
I'll spare you the controversy and simply say that this does exactly what you want it to. The Abstract of the spec says it all.
This specification defines an API that enables Web pages to use the Web Sockets protocol for two-way communication with a remote host.
Special Mention
If you are interested in the world of Node JS, you can't go wrong with Socket IO. It will implement the best of whichever technology is available to the browser.
Conclusion
The best option is Socket.IO on Node JS. However, for an ASP.Net solution, go for COMET or Web Sockets, if you can. Otherwise, using Flash/Silverlight isn't terrible. Finally, polling and long polling should be last resorts. You could always support one of these, then fall back to another if there isn't support for it in the client's browser.
Yes, you can use COMET.
The client has to tell the server when the client-user begins typing. You've got a couple options here.
Frequent requests from the server for the latest activity. This would be taking place for each user involved in the chat. The same request could be used to send user-specific activity to the server as well: "Jonathan is typing..."
Long-polling. This essentially requests information from the server, and the server keeps the connection opened until it has something to send back. So your requests are minimized, but your connections stay opened longer.
Depending on your traffic, type of data being transmitted, server-environment, and many other factors, one of these options may shine more than the other.
You can use Silverlight for push notifications. Look at PollingDuplexHttpBinding. Since you are using ASP.Net MVC, adding Silverlight will be easy.
Look at this page for more information.
Based upon the REST architecture the html system is based upon, the servers role is to simply act as a resource for the client to pull from. I am generalizing but there are tools to implement this type of action on the client side, rather than on the server side.
You are better off writing/using a library that can request updates from the server periodically. You can encapsulate these types of requests in a javascript object that can fire events. This way your client side script can act like it's getting notified from the server. Review some common stuff with COMET you can probably find some tools to help you client side code.
HTML 5 has some tentative attempts at this type of functionality, but if you want your app to work on older browsers, your better off using more stable methods, like AJAX requested updates.