Podcast: Play in new window | Download
Subscribe: iTunes | Android | RSS
Justin and Jason discuss Udi’s stay in Pasadena and his working relationship with Justin, how to manage sessions between a Javascript client and a RESTful API, solving the Catalyst network problems and why Jason thinks Javascript isn’t the easiest language for kids to learn, thoughts on the Code.org video, how Pluggio was hacked, the evolution of the Catalyst stack and how Jason uses Node.js in combination with LAMP, the tradeoffs of building a startup on cutting edge technologies, the progress being made on AnyFu, the results of the Uber nearest cabs challenge, Jason’s thoughts on the Upverter hackathon, the SHIELD Act and how patent trolls are going after popular podcasters, Justin’s TV recommendations and why Jason listens to podcasts about the The Walking Dead, and Udi’s concluding thoughts on America.
You made me shout at the radio today… Session ids are not the same as auth tokens. Having auth token doesn’t make the API stateful. You can have unique, random auth tokens which you check against a database to get back username. You can have auth tokens which are just base64 encoded, symmetric encrypted username+timestamp, using a key specific to the application so that the user sees a random string in the cookie, not the actual data – in that case you don’t have to check it in the database (just decrypt to get username). Having another server doing authentication based on tokens is reinventing kerberos, openid, etc. Most of this is already implemented in pretty much every framework available in public! Deep breath…………. Ok, going back to listen to the rest of the show 😉
On another topic: I’m interested how did you treat indentation so far in Catalyst? Was it just “this is a nice thing to do” / “you have do this, but your program may just happen to work without it”, or somewhere in between?
Hello all, long time listener, first time commenter.
By the way the show is great and the sound quality for the episode was not too bad, even though I know production values are a point of pride for Justin.
Regarding stateless authentication schemes for restful’ish web services there is always HMAC ((Hash Message Authentication Code).
In effect you “authenticate” each request/response by signing and hashing (request data can then be verified and be protected against modification). Using short time windows for request/response cycle mitigates against replay attacks.
As I’m sure you already know the major benefit of a stateless over stateful approaches (apart from the noble motive or achieving restful purity 🙂 ) is that scaling becomes less complicated. As more servers are added you no longer have to worry about session replication and all that guff.
Here’s a nice short post on HMAC (http://appsandsecurity.blogspot.co.uk/2011/04/rest-and-stateless-session-ids.html) and a more chatty and fun post (http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/) by an AnyFu expert no less! Maybe you could book a session with Riad 🙂
Have you checked out Clarity.fm? They seem similar to AnyFu but with a different focus (business vs tech). They might become a competitor or have partner potential – which I know Jason would love! 🙂
You might want to look into using Lua as your language of choice for Catalyst. It is structurally very similar to JS, but uses words instead of brackets and semicolons. Lua is also a useful language to learn because it compiles to sooooo many other languages.
Here’s a Lua to JS compiler: https://github.com/mherkender/lua.js#readme
You can also use Lua to program native mobile apps, using the Corona framework to compile to Objective-C and Java. http://www.coronalabs.com/products/corona-sdk/
Here’s a kids alphabet-learning app – http://johnpolacek.com/matchtheletter/ – I made with it a couple years ago for my son. Open sourced the code on Github: https://github.com/johnpolacek/Match-The-Letter-Game/tree/master/source
Lua has been around forever, but it has slow steady growth in usage as more people discover it. For example, this recent article on HN about using it to augment nginx: http://news.ycombinator.com/item?id=4892655
finally. I almost posted this yesterday :””(
Thanks 🙂
Regarding the API discussion, can’t it be as simple as:
client front-end client back-end public api
So, you you trigger an API call from the front end, which hits a small interface to the API on your back end, which knows the session information and can send auth info to the API in the same way that a 3rd party would. You eat your own dog food and you remove the front-end from the authentication handshake.
In my previous comment some characters were stripped. It should read:
client front-end client back-end public apiRah!
client front-end *INTERFACES WITH* client back-end *INTERFACES WITH* public api
TL;DR – Justin says don’t send the authenticating user id in API calls because it makes your system super easy to pwn
—
The strange thing is that it seems like no one is understanding the actual argument Udi and I are having about the api.
He says, the api request should look like this.
my_user_id = 1
affecting_user_id = 10
action = promote to admin
All I am saying is that you should not send “my_user_id” as a parameter.
Rather than send “my_user_id” as a parameter the api/server should workout who you are based on the authenticating credentials. I don’t care how that authentication happens. Session, token, hashing, etc.
All I am saying is, the application logic needs to be stateful based on the connecting user. The idea of sending my_user_id as a parameter seems crazy to me, and opens up a huge security hole.
The (rather obvious) security hole is.
1) Login with a standard account that does not have admin status
2) Open the dom with firebug
3) Change “my_user_id” to one of an admins id
4) Submit a request to upgrade myself to admin
5) Now I’ve pwned your system
Udi, says that a “stateless” api is stateless because the API request should contain all parameters required to deal with “stateful” application logic.
But, that is not what is meant by stateless api. All it means is that each api handshake should contain the credentials and parameters to perform the action.
But it is perfectly acceptable to lookup “my_user_id” based off the authenticating credentials rather than submit them as a parameter.
@Stanislaw Pitucha – All I mean is that the concept is similar. In all cases you are sending a random string of characters that the server uses to authenticate you and look up a user based on the authentication details, rather than sending your actual user id.
@Bill – I’ve met Dan a couple times and he emailed me a while back about how they were going to pivot into the AnyFu space, so yeah, I’m very much aware of Clarity.fm.
You’re right, I wasn’t interested in partnering. 😉
@John Polacek – Yeah, I’ll take a closer look at Lua, especially since there’s a Lua to JS compiler. That would allow me to integrate it into the web-based Catalyst IDE. Thanks so much for the links! 😉
I’m enjoying this show but I wanted to comment on Jason’s comments in regards to the Code.org video. Firstly, i’m disappointed that he didn’t actually watch it…..come on, if you’re going to give opinion on it, at least watch it. To be clear, the message of the video is not “everyone should be a coder”.
Secondly, marketing coding as something that is interesting as a possible career is a powerful message. I don’t see any downside to this, period. The result will be that more people will check it out….and that’s a good thing. Yes some will fall away but more will check it out. Bravo code.org, bravo.
@Justin – “I don’t care how that authentication happens.” – I guess that’s the part that was not clear from the podcast. If Udi was proposing sending user_id in plaintext and not verifiable… that’s a huge issue.
If he meant it as a general concept where my_user_id can be either proven correct by another value, or can be decrypted from the session identifier/token itself, then no – that can be done securely.
So… we may be just violently agreeing with each other… 🙂
@Jordy – I watched the video a couple days ago and the long version turned out to be exactly like what I assumed it was going to be. I would have watched the video if it was a topic I had planned to bring up and discuss, but Justin surprised me with it, so I just said what I thought. Anyway, the opinion I gave wasn’t so much on the video itself, but on the obvious message of the video.
Came here expecting a million comments about the statefull/stateless API and so there is.
Personally I prefer stateless API’s, but where you have all of the client code in the clear (inspect element) you are kinda hosed when it comes to security unless you do as Justin did and verify everything on the server side.
I suppose you could pass back tokens and use that as a salt to hash all details you send to the server and update it on each API call to ensure that everything is from the same user. Essentially signing everything back to the server using a unique key every time.
To hack something like this would be pretty difficult especially as you would need to know the person you are trying to hacks hash for their next API call, and beat them to using it. Over SSL/TLS that would be pretty dammed hard to do.
That would get around having cookies/sessions but you would be maintaining the state yourself. Would make the API easier to test (no need to implement cookies/sessions) but not any better IMHO.
on the code.org discussion:
It seemed to me like Jason was arguing that everybody who learns to code becomes a “software developer”, leaving out all the other benefits learning to code can have.
I think coding teaches you a way to think, abstraction, learning how to break a big problem into smaller ones, and that has benefits on all aspects of life.
Every kid gets thaught math and how to wrtie/read, but that doesn’t mean every kid becomes a mathematician or author. Those are just skills you need to help you master life and learning to code will have the same effect.
Just want to add a +1 for the Lua suggestion. It’s a brilliantly simple and coherent language in all the ways JavaScript is not. JavaScript will be getting much worse and much bigger if the TC39 committee continue on their current course.
Great episode as usual.
@Jason: can you link to the article you mentioned regarding “100,000 spaceships” as it regarded your optimization efforts?
@Harold – Here’s the link, but I guess it was 10,000 and not 100,000 spaceships. 😉
* A New Approach to Databases and Data Processing — Simulating 10Ks of Spaceships on My Laptop
http://blog.paralleluniverse.co/post/44146699200/spaceships
Okay okay okay, let me fix some of the damage Justin did 🙂
First of all, the “stateless” thing I want is basically that the API won’t store anything related to a “logged in user”.
I want the API to know clients, to know apps that work with it.
I want the CLIENT app to keep track of what user is logged in AND WHAT ITS ALLOWED TO DO, otherwise, with Justin’s solution, you can fake each request ANYWAY.
The misunderstanding with sending user_id – its a problem not because of what I want to do/say.
Let me explain:
– Originally the API was built as a set of tools, “Do X, Do Y, Do Z on user_id = 7”. The issue is around “Is the current user can Do Z on user_id = 7?” I’m not sure letting the API to deal with it is the right idea for many different reasons.
– Justin doesn’t want to have any cookies on his end in JS app, he rather let the API deal with it.
Sending user_id of the logged in user was a suggestion that I didn’t insisted on, and I still think that JS app should handle the who it is and what it can do.