Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fixing typos

  • Loading branch information...
commit 4a59f308dc4d3844862e3f0cd7f4e0cdf589999b 1 parent eb87263
Shahar Kedar authored
Showing with 7 additions and 8 deletions.
  1. +7 −8 articles/socket-io-auth.markdown
View
15 articles/socket-io-auth.markdown
@@ -5,28 +5,28 @@ Node: v0.8.15
## Prolog
-I decided to write this article after getting a bit frustrated from searching the internet for a descent example on how to use session based authorization with socket.io. To be honest, socket.io wiki page on [authorization](https://github.com/LearnBoost/socket.io/wiki/Authorizing) was quite simple to follow and understand, but when it came to **session based** authorization, I got a bit lost (especially considerting the fact that it's my third day using Node...).
+I decided to write this article after getting a bit frustrated from searching the Internet for a decent example on how to use session based authorization with socket.io. To be honest, socket.io wiki page on [authorization](https://github.com/LearnBoost/socket.io/wiki/Authorizing) was quite simple to follow and understand, but when it came to **session based** authorization, I got a bit lost (especially considering the fact that it's my third day using Node...).
## Reading Suggestions
Before reading this article, I strongly suggest you get familiar with Express and Socket.IO. I kept things as simple and minimal as possible, so you really don't need more than a couple of hours to learn what needs to be learned if you're a complete newbie.
-I also suggest reading the Authorization wiki page referneced in the prolog.
+I also suggest reading the Authorization wiki page referenced in the prolog.
## Global Authorization vs Namespace Authorization
First I would like to distinguish between two authorization scopes that are currently supported by socket.io, namely - Global and Namespace. *Global* authorization will be used to authorize any attempt to open a (socket.io) connection against our Node application. *Namespace* authorization, on the other hand, allows you to use different authorization rules when accepting connections to a specific socket.io namespace (more on namespaces can be found [here](http://socket.io/#how-to-use))
-In this article I will examplify only how to enable Global authorization, although from the looks of things, namespace authorization is quite straightforward once you understand global autorization.
+In this article I will exemplify only how to enable Global authorization, although from the looks of things, namespace authorization is quite straightforward once you understand global authorization.
## A Few Words about Timing
-It's important to understand that the authorization process takes place during handshake. This means that, prior to authorization, no socket connection is established. As a matter of fact, because the handshakes in socket.io are implemeneted as HTTP calls, one can use the HTTP context to get relevant information on the user who's trying to connect. As you'll see next, I will be using cookie data to authorize any user that tried to establish a socket connection to the server.
+It's important to understand that the authorization process takes place during handshake. This means that, prior to authorization, no socket connection is established. As a matter of fact, because the handshakes in socket.io are implemented as HTTP calls, one can use the HTTP context to get relevant information on the user who's trying to connect. As you'll see next, I will be using cookie data to authorize any user that tried to establish a socket connection to the server.
## Session-based Authorization
-As I said, I will be using cookie data to authorize our John Dow. Specifically, I will be using the user's session id to make sure that indeed this user went through the system. The trick here is to use Express' session middleware to assign a **signed** session id to the user, so the next time he sends a request (in our case that would be during socket.io handshake) it will be possible to ascertain that this user is a valid user and not a scoundrel. Theoratically, I could also fetch more information about the user using his session id, but I felt that it's out of scope for this article. I admit that this kind of autorization method is naive, but it's good enough to get you started.
+As I said, I will be using cookie data to authorize our John Dow. Specifically, I will be using the user's session id to make sure that indeed this user went through the system. The trick here is to use Express' session middleware to assign a **signed** session id to the user, so the next time he sends a request (in our case that would be during socket.io handshake) it will be possible to ascertain that this user is a valid user and not a scoundrel. Theoretically, I could also fetch more information about the user using his session id, but I felt that it's out of scope for this article. I admit that this kind of authorization method is naive, but it's good enough to get you started.
## Time to Code!
@@ -66,7 +66,7 @@ Now we're getting to the tricky part. First we need to bind socket.io to our HTT
The next block is the reason we're all here - by calling <code>io.set('authorization', function (handshakeData, accept)</code> we instruct socket.io to run our authorization code when performing a handshake.
-The logic goes as followes: first we check if there's a cookie associated with the handshake request. In case the user already logged into our system there should be a cookie containing his session id. If no cookie is found the user is rejected.
+The logic goes as follows: first we check if there's a cookie associated with the handshake request. In case the user already logged into our system there should be a cookie containing his session id. If no cookie is found the user is rejected.
If a cookie is found, we try to parse it. The crucial line here is <code>connect.utils.parseSignedCookie(handshakeData.cookie['express.sid'], 'secret')</code>, which tries to unsign the session id cookie value using the same secret key used for signing. If the cookie was indeed signed by our server than the reverse operation should give us the real session id. This is actually our way of making sure that the user trying to connect is someone we "know" and not some fake user trying to hack into our system. Notice that in case we did not succeed in unsigning the value, the return value should equal to the original value, indicating a problem.
@@ -74,5 +74,4 @@ The next couple of lines in the full source code are standard socket.io and I wo
## Epilogue
-That's it! You're ready to implement whatever autorization algorithm you want. Enjoy socket.io!
-
+That's it! You're ready to implement whatever authorization algorithm you want. Enjoy socket.io!
Please sign in to comment.
Something went wrong with that request. Please try again.