Ember-simple-auth: Support Fastboot

[maletor]

I think fastboot can be supported without much effort.

Currently, we get an error "Error: Failed to create an instance of 'session-store:application'." This is from an instance initializer.

[marcoow]

A prerequisite for supporting Fastboot is having an abstraction for cookies access that works both in the browser as well as in Fastboot. I put ember-cookies together that does that. It' missing tests currently but shouldn't be a big deal to add those. Once that's in place it should be pretty easy to support Fastboot in fact.

[joelcox]

Great to hear Marco. Has anyone found a temporary workaround to get a FastBoot build without removing the Simple Auth module and session injections?

[jfarlow]

Just another voice saying great work so far, and FastBoot support would be greater still :)

[marcoow]

@jfarlow: I'm pretty sure FastBoot support is coming with 1.2.

[arjansingh]

@marcoow are you actively working on ember-cookies integration? If not I'd be happy take shot at doing it.

[marcoow]

@arjansingh: I'm currently focussed on finishing ember-cookies itself.

@briangonzalez said he wanted to get started with implementing FastBoot support - maybe you guys want to pair up on that.

[arjansingh]

@marcoow considering @briangonzalez and I sit next to each other at work, that should not be a problem. 😎

Is ember-cookies safe to integrate into the solution? That's part of my plan.

[marcoow]

ember-cookies should be fine to integrate. The only 2 open issues currently are https://github.com/simplabs/ember-cookies/issues - simplabs/ember-cookies#8 is obviously about code style only and simplabs/ember-cookies#7 is only necessary to make sure an edge case works in FastBoot so the library's behavior is consistent but it's very unlikely that you run into that. I'm also planning on completing both issues today and release a new version.

[marcoow]

@arjansingh, @briangonzalez: I release ember-cookies 0.0.3 that contains the changes mentioned above: https://github.com/simplabs/ember-cookies/releases/tag/0.0.3

[arjansingh]

@marcoow: Waiting on https://github.com/ember-fastboot/ember-fastboot-server/pull/38 to get merged into Fastboot Server. That'll give us access to the server request.

[marcoow]

You can already access the request via the fastboot service's fastbootInfo property. Would be cool to have a clean public interface to that of course.

[maletor]

@marcoow, one thing we need to make sure we keep in mind is the CSRF attack. As I'm sure many people will want to use Fastboot, it's requirement for cookies based auth is a requirement for a CSRF token. It's probably not responsible to not least support or document what needs to happen to make the application secure using cookies.

[mike-north]

@maletor - definitely have a valid point in many cases, but be sure you don't confuse using a cookie-based session store with using cookie-based authentication. For example, if you have your UI hosted on a domain _ui.myapp.com_ and an api on _api.myapp.com_, using a secure cookie under the domain for the UI as your session store is really no different than using localstorage (except that it works with fastboot).

[maletor]

I think they are different. Maybe I'm not seeing it, but follow along with me.

An attacking website (e.g. bad.com) can send a DELETE request to ui.myapp.com/user in a self submitting form and the credentials will travel with the request in the cookie whereas with localStorage they would not. In a functioning Ember app, the cookie credentials would be translated into the access token for use with the API and would delete the user.

Without Fastboot, that request to ui.myapp.com/user will be completely harmless since the app isn't setup to serve a POST request like that. If it doesn't return a 404 or 405, it might return the HTML of the index.html page, but all harmless.

If my understanding of Fastboot is correct, the app will process the POST request, including deserializing the cookie to send to the API.

For that reason, the Fastboot app should maybe not process anything but GET or HEAD requests (maybe this is how it works now), or if it's going to process a POST request it should check that the request Origin header is either not present or found in a whitelist.

[maletor]

Nevermind I guess. I read the Fastboot source code and it looks like non safe requests (everything but GET) are disallowed. With Fastboot not allowing state changes, that obviates any CSRF attack.

[mike-north]

@maletor - I think you do have a point though. As people shift more to using cookie as a session-store, some portion of them will actually want their APIs to read those cookies directly. Once you're in that territory, you absolutely need CSRF. For now, we have a path forward, and that's for your UI to read the cookie directly, and then submit the creds via a header (and, on your API side, pay attention to the Origin header).

[maletor]

Is that actually a threat though?

Fastboot not allowing state changes by virtue of only responding to GET requests _should_ mean that the Fastboot server won't make any state changes on the API server. It would only be if the Fastboot server, in turn, did a POST request on the API as a result of a GET request on Fastboot. Hopefully nobody does that?

There's no need to check Origin headers on the API so long as you aren't doing cookie based authentication. Similarly for the Fastboot server since all requests are "safe".

[BenKingBBC]

Why is this closed? Does Simple Auth support FastBoot now then?

[marcoow]

@BenKingBBC: see follow up: #964

[marcoow]

@maletor, @mike-north be aware that FastBoot will never handle POST requests - it's not an API but simply a pre-renderer for your app that should always only handle GET requests.

Ah sorry, you already discussed that above…