User Authentication with Rails and Backbone.js

http://42floors.com/blog/posts/user-authentication-with-rails-and-backbone-js

by waratuman • 14 years ago

69 17 14 years ago

42floors.com

darius• 14 years ago

Or just use devise. Backbone will work just fine with it.

mshafrir• 14 years ago

Does Devise handle XHR and JSON (requests/responses) out of the box?

atomical• 14 years ago

Yes.

1.3.1

*sessions/new and registrations/new also respond to xml and json now

patio11• 14 years ago

You probably want attr_accessible in there.

YuriNiyazov3• 14 years ago

One of the fundamental difficulties of handling login with Backbone.js is that your regular site is usually served off HTTP, but you want to send credentials via HTTPS, which requires various hacks, or a full page refresh. By posting up something that doesn't handle that problem, I'm afraid that the OP is putting a newbie who isn't aware of that problem in danger since they are apt to copy this tutorial verbatim.

pushtheenvelope• 14 years ago

Thank you for pointing this out. As someone who hasn't explicitly tried out backbone.js yet but wanted to use it for a future project, this is something that was at the back of my mind.

waratuman2• 14 years ago

Yes, this is true. I'll mention this in an update. When working in dev I've always just used regular HTTP. I'll mention how to configure Rails to use SSL.

jashkenas• 14 years ago

What "various hacks" does submitting an HTTPS login form require?

For what it's worth, if you want real HTTPS security, you can't serve pages from your "regular site" over HTTP -- especially pages with a login form on them -- doing so is an invitation for a man in the middle to step in and phish your visitors.

YuriNiyazov3• 14 years ago

I do not mean submitting an HTTPS login form, which works just fine, but forces a full page refresh. I mean capturing a submit and sending the credentials via AJAX, but to HTTPS, which is forbidden by the security sandbox. You end up doing various unkosher things like bringing up the login form over HTTPS in an iframe while the site itself is brought up over HTTP.

Yes, this is fundamentally insecure, and I am aware that this is not a problem with Backbone specifically, but a general problem with the approach of building browser apps without page refreshes over HTTP for everything except for the login screen.

pilif• 14 years ago

If you are transmitting the login information over SSL, I would assume that you already have SSL configured. Why not just serve the whole site over SSL constantly? That would fix this issue and provide better security by making it impossible for a MITM to redirect the login form to the HTTP version (or, if you are using an iframe, MITM the iframe over plain HTTP)

awj• 14 years ago

> Why not just serve the whole site over SSL constantly?

Because now you have to serve every single bit of your page over SSL (to avoid security warnings) and that means none of your page content can be cached. It also makes relatively mundane things, like having your proxy server communicate the originating ip address, much harder. I can set up haproxy to add an X-Forwarded-For header in almost no time flat. In fact I just gave you enough information to google that solution for yourself. Solving that problem over SSL is much harder.

Engineering a MITM attack is much more technically difficult than snooping traffic. Not every company actually need to turn the security knob up to 11 on this aspect, and being able to do unencrypted-page-with-encrypted-login is a good trade-off when you can make it.

benologist• 14 years ago

As always this looks like very useful information for people looking for office space!

rurounijones• 14 years ago

Why the custom password handling when they could just have used rail's new http://apidock.com/rails/ActiveModel/SecurePassword/ClassMet... feature?

User Authentication with Rails and Backbone.js

Related Stories