 how we do. Or it's now in Ember and how fast would just change that and what to be aware of in general. I'm Marco, Marco at W on GitHub and Twitter, I'm the founder of Simplabs, we're a consultancy in Munich and we focus on these three things, Ember Rails and Phoenix recently, so if you need any help with that, then just talk to me. And we're doing Ember workshops as well. You can go to that website for details. So leaving that marketing stuff behind us, back to the topic, you recognize that that says Auth Star in Ember instead of an actual word and that's because in that context actually means two different things. First of all, you have authentication which is the process of verifying the user's identity which you usually do by validating their credentials and if those credentials are valid then you assume that someone who knows those credentials must be that user or you might trust a third party to do that validation which is the case when you allow people to log in with Facebook for example or Twitter or LinkedIn for that matter. And then once you have authenticated the user then comes the authorization step where you verify that that person is actually allowed to do or see something that they request to do or see. But something you have to be aware of is that inside of an Ember app you cannot actually do any of these things because the source code is in the browser and the state is in the browser so that's all accessible and editable by the user of course. So at any point in time you might just fire up the Ember inspector and do that and then you're suddenly authenticated. So assuming you have something like a session service or so that you assign to dollar here, you could also assign roles for yourself during runtime. So the actual authentication and authorization always happens on the server side, on the API server side which can do it in a secure way actually and can actually prevent access to data or modifications to data and in the case that something is not allowed would just respond with a 4-1 response. So that means that authorization in the Ember app itself is only about displaying a consistent UI so that you don't display anything that the user is not allowed to see and if they were able to see it wouldn't work for them anyway because the server would reject access to the data that that particular route needs. So let's have a look at how we do that now without fastboot and the status quo is basically using token-based authorization where the token is issued by the API server or maybe you have dedicated auth server during authentication and then it's injected into all subsequent requests and most cases those will be Ember data requests. So the authorization actually happens on the server side. Let's look at an example for how that looks from the first request that loads the application. So here we have the client, the app server that serves your HTML and JavaScript and the API server. So first of all of course the client sends a request for the HTML file which responds then with that more or less empty index on HTML that just contains the script text. Then the client files a second request to load those, to load the JavaScript. Once that is loaded the Ember app starts up, renders the page and from now on takes over and everything runs on the browser of course. Then when the user logs in they would send some credentials to the API server, get a token in response and then in all subsequent requests would include that token with the request so the server can authorize that request and reject it if that's not allowed. So how does that change when we're using fastboot? First of all a quick recap of what fastboot is. So the slogan is progressive enhancement for ambitious web apps and for now that mainly means that fastboot performs the initial render of the page on the server side and so reducing the time that it takes until the user first sees some content that runs. So it basically makes the startup feel faster for now. And then after the JavaScript has downloaded the Ember app starts on the browser and everything runs as it would normally do without fastboot as well. And that's also the progressive part I think because if the client does not have JavaScript enabled then it would not start up the application in the browser of course and all the links in the application that would usually result in route changes in the application would just result in a request that would go to the fastboot server, fastboot server would render that route that matches that request and would respond with the rendered page so you could actually use the application without having JavaScript enabled in your browser. So let's look at how the previous example changes when you have fastboot enabled and here we are assuming that the user has already authenticated previously and it's just re-learning the page. So first of all you have that HTML or the request for the route that should then respond with the respective HTML that goes to the fastboot server. The fastboot server would then load the data that it needs to render that route from the API server just like the browser does including the token of course because that has to be authorized or potentially has to be authorized. Like you might have something that just allows reads from anywhere but of course we are assuming that request requires authorization then the page gets rendered or pre-rendered in the fastboot server it responds with that pre-rendered HTML file and then you have the second request of course for loading the JavaScript and then the application runs on the browser as usual and of course if the browser then reads any data then would include the token as well and any request to the API server. So of course you recognize that the fastboot server also needs to include the token in the request that it sends to the API server. So the question is how do we get that from the browser to the fastboot server and we need a way to do that that does not require us to execute a JavaScript of course because when the request is being made then that's when you're reloading the page so you have no way to execute any of your code. So what we would need is a floating session kind of which ensures a singular execution context in the browser as well as in fastboot so that the response that the fastboot server pre-renders is the same thing that the user would see when looking at that stuff and rendering the stuff in the browser. And the good thing is we have a technology for that since 97 and that's of course cookies because as soon as you have a cookie for some domain then it would always be sent with a request to that domain. So the idea would be if we look at that example again to just store the token in a cookie that would get sent along with the request that goes to the fastboot server and then the fastboot server would just be able to read the token from the cookie and would have it to make the request to the API server. Of course there is one problem with cookies in the EU at least that you have to show these things but for those of you who are in Britain you can just thank these nice gentlemen who just liberated you of that stupid rule or they are not actually going to do anything about that but at some point you can probably remove those warnings. But there's also another problem that would affect people in Britain as well for the long term and that's the fact that there is obviously no document cookie in Node.js. So you cannot just use document cookie to store the token in a cookie and read it from that because that would just not work on the fastboot server. So what do we do? The good thing is there is an add-on called ember cookies which is a cookie abstraction that works in the browser as well as on fastboot providing the same API so in the browser it would just use document cookie and on fastboot it uses the request response object. And now I have an example that I want to show you that's available on GitHub so you can check it out there. Let me just, I don't want to reboot now. All right. So the demo application is pretty simple. We have a private route here that requires log in, as soon as I'm logged in I'm allowed to access that and when I reload I get the same, get the actual private data. Let's look at the implementation for that first. So we have a session service here that uses the cookies service that's provided by ember cookies and we have token property here that just reads and writes from the cookie and then it has an authenticated property as well. That's true if the token is not empty so we assume that if the token is present then the user is authenticated then for logging in, basically when the user logs in we just take the credentials, send them to the server if that request is successful, we get the token in the response, write it to the session so it's being written to the cookie through that session service and then transition to the index route. And then last thing is looking at the private route that just in the before model just checks whether the session is authenticated, if not then transitions to the login route and in the model method we just load the private data sending that authorization header including the token along with the request. So that means I showed you that earlier that when we reload the page and are authenticated we get a response or basically in the request you see that the cookie is being sent of course and the response includes the private data that's being fetched from the API server by the fastboot server sending the token and the authorization header. So if we now delete the cookie and reload the page then you see we are redirected to the login page via a proper 307 redirect because fastboot translates that transition to the terms in the before model of the private route into an HTTP redirect. So that's the example. So you see it's actually pretty simple to do that as the HTTP only flag. And the idea here is that instead of when the user logs in instead of sending the token in the response for that request just sending an empty response and setting a cookie that's not accessible for JavaScript and then that cookie would of course still be injected into subsequent request because in this example the fastboot server and the API server share the same domain that they run on the same domain they of course also share cookies so the cookie that the API server sets when the user authenticates would also be included in this request when you reload the application or loaded the next time so that the fastboot server can read that cookie included in the request to the API server and would get the respective response. Yeah like I said already that has implications on your domain setup of course so basically your your app domain and API domain have to be set up so that the cookie that the API server sets would also be included into request to the app server. In this example you have the app server running at app.com the API server API.com so the cookie that the API server sets would not be included here which means that fastboot would not be able to include it in that request and then the whole thing that would just not work. So let's look at an example for that and I just figured out the morning that the code that's on GitHub for this example does not actually work so I will fix that but like I have fixed it on my machine obviously but I haven't pushed that yet and note that in the same repository just a different branch. So what we have here I'm running an engine X here so I can can can properly share cookies so it's the same example the private route requires requires authentication when I load that I see the private data when I reload that then I get the proper response from from fastboot so let's look at the code for this real quick here we the session service is a bit simpler we just have that that is authenticated property that just reads and writes through to and from the cookie but in this case we're just storing whether the user is currently authenticated yes or no and then on login it's this is pretty similar to the previous code basically that just sends the user's credentials to the server but the difference here is if we get a successful response we just set the authenticated property of the session to true and we don't get a response body in this case but the cookie will be there we have no way to actually see it from the JavaScript code of course but we know that if the response is successful that response will also include the set cookie header that will set that HTTP only cookie and then the private route is the same thing as no it's not the same thing as before before model is the same thing as before and in the model method we now have to have to do two different things depending on whether we are running in in fast boot or or in the browser that's something that might be possible to abstract as well so that you don't have to have to do that check for fast boot in your code but for now you have to do two different things so if you're running in fast boot you have to read the token from the cookie right the fast boot server of course has access to that cookie because it's not a browser it's a server so that HTTP only flag does not matter in this in that case so we read the token from the cookie and just set the cookie header that's then being sent along with the request to the API server if we are running in the browser we just set these with credentials properties so that that the Ajax request would also send the cookie along with the request if we look at if I log out again and then we can have a look at the actual request and responses so like I said if when we log in we just get a two or four response no content but the request the response headers also include that set cookie header that sets that token cookie with the HTTP only flag and then if we go to the private data route then you see request the private data and includes that that that a cookie holding the token in the request as well if we reload then see that we get a first of all of course the cookie is included in this request as well we get the proper response from fast boot with that pre-rendered route and again if we delete the cookie then it's a 307 response redirecting to the login route alright so that's a one last attack vector that I want to talk about quickly and that's cross-site request for three so as soon as you're using cookies you might be vulnerable to cross-site request for three attacks what that means most of you probably know is that someone gets to gets to initiate request in like in your user context without your knowledge or consent so if you happen to have a bank account on bank.com and do your banking stuff there and then never log out and then you're looking at a page that has that HTML there then the browser would actually send that request and would send one million to the attacker if you happen to have the one million of course there are several mechanisms to prevent that so that would not work for most banks probably but it's still a potential problem and of course the point is that if you have a cookie for the bank.com domain then it would be sent along with that request right so the user the server might actually trust that authentication or you might get an email from some friend that's supposedly supposed to contain like some CR7 pics but actually has that malicious link so the point is that when you're using the authorization header for authorizing API request then CSRF does not work because the authorization header would not be included in the request by the browser but of course when you're using cookie authorization then you might actually be vulnerable as that cookie would be sent along with the request of course however CSRF results and get request so if you have a proper REST API then that would not be such a big problem but the more interesting thing anyway in this context is that of course the attacker could also initiate a request to the fastboot server right and depending on what you do in your in your routes on the fastboot server that might actually be a problem the good thing is for now fastboot only pre-render so it doesn't execute any actions that might lead to undesirable actions in that case because actions would of course require user interaction which does not happen in fastboot so basically what you need to be aware of or what you should do is to not perform anything potentially unsafe and before model model after model because these things actually run on the fastboot server and if you have a route that in the before model does something you need to make sure is actually initiated by the user then that's probably probably wrong the good thing is you're probably not doing that anyways because these methods are basically just responsible for loading data of course and maybe redirecting or so but the thing you have to be aware of is that you're now exposing a part of your Ember app via an HTTP interface right so to wrap up you use token-based authorization you store that either via the authorization header or via via via a cookie and you use in in in both of those cases you're using a cookie to transparently remove the authentication state and and any authorization information that you have between the browser and the fastboot server in the case that you're using an authorization header for authorizing API request you you store the the token in the cookie yourself and in the case that the the API server sets the cookie itself when the user authenticates then it will already be there and if your domains are set up correctly will be sent along with requests that then are handled by the fastboot server and of course you have to make sure you're safe so one last thing I want to say is you could of course implement all these things yourself or you could just use the upcoming Ember simple auth release which will support support fastboot and out of the box it's hopefully going to come soon we're working on that yeah that's it thanks