Chapters
26 Chapters
|
2:18:26
|
This course is archived!
This tutorial uses a deprecated micro-framework called Silex. The fundamentals of REST are still ?valid, but the code we use can't be used in a real application.
Login to bookmark this video
-
Course Code
Subscribe to download the code!
Subscribe to download the code!
-
This Video
Subscribe to download the video!
Subscribe to download the video!
-
Course Script
Subscribe to download the script!
Subscribe to download the script!
04.
Requiring Authentication
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Subscribe to jump to this part in the video!
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
This tutorial uses a deprecated micro-framework called Silex. The fundamentals of REST are still ?valid, but the code we use can't be used in a real application.
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"silex/silex": "~1.0", // v1.3.2
"symfony/twig-bridge": "~2.1", // v2.7.3
"symfony/security": "~2.4", // v2.7.3
"doctrine/dbal": "^2.5.4", // v2.5.4
"monolog/monolog": "~1.7.0", // 1.7.0
"symfony/validator": "~2.4", // v2.7.3
"symfony/expression-language": "~2.4", // v2.7.3
"jms/serializer": "~0.16", // 0.16.0
"willdurand/hateoas": "~2.3" // v2.3.0
},
"require-dev": {
"behat/mink": "~1.5", // v1.5.0
"behat/mink-goutte-driver": "~1.0.9", // v1.0.9
"behat/mink-selenium2-driver": "~1.1.1", // v1.1.1
"behat/behat": "~2.5", // v2.5.5
"behat/mink-extension": "~1.2.0", // v1.2.0
"phpunit/phpunit": "~5.7.0", // 5.7.27
"guzzle/guzzle": "~3.7" // v3.9.3
}
}
6 Comments
Rather basic question for a change, why do we need to have a POST request to create tokens. Can't a token be created together with the creation of a user account? So that when a user registers, a POST user request is made, creating a user and an apitoken for that user in the database, and returning the token for the user to keep browsing? Or I am just simply wrong and the idea is that a token is created for every session?
This is how I understand it so far so please correct me if wrong:
REGISTRATION IN A JS APP
1. User fills a form that sends a POST users request.
2. Server validates and creates the user (* possibly creating a token for the user too) and maybe sends a confirmation mail(?)
3. Server returns token to the client app, which will add the token in every future request.
LOGIN
1. User fills a login form that sends a ?????? request.
2. Server validates the user through Basic Auth, retrieves the token for that user and returns it to the js app.
3. The js app attaches the token to every future request.
I'd really appreciate if you could elaborate on this :) Thanks!
Hi Joan!
Great questions as always :). First, let me talk about the LOGIN part. Basically, the flow you have setup is correct, though I'll make 2 points:
1) If it's YOUR JS app on YOUR domain, you could just have the user login like normal and create a session (like a traditional website). Then, all requests that are made from JS are authenticated, because they carry the session with it.
2) If it's NOT your JS app, then things get interesting due to security. Ultimately, the JS app needs a token, and you can decide if this lasts for 10 minutes or 10 years. In this model, there is no session, so you can't think of it as "this token lasts for this session". In our app, the tokens last forever - you have to weigh the security implications of that. So, if you *were* to login with a JS app, it would look something like this:
1) User sends a POST request to create a token. That request somehow contains authentication information (in our app, we did this with HTTP Basic auth).
2) ... same as your #3
This whole "what's the best way for a client to retrieve a token?" question relates to OAuth, whose whole job is to basically help a client securely get an access token. Again, this only applies if you're truly opening up your API to third parties, but if you are, then you'll probably be well-served by setting up your app to be an OAuth server and replacing my (1) above with an OAuth flow that a client can use to get a token.
Oh, and last thing. You of course *can* create a token right when you create a user. Heck, the token could just be a property on your User, not a different resource. I decided to allow a User to have many tokens because I might want 10 different tokens that I give out to 10 different API clients (e.g. other sites that integrate with mine, iPhone apps, etc). Then, I could revoke any token to revoke access to just *one* of those clients, instead of needing to change my *one* key and update it in all of the places that I still want to give access to. Again, this is all in the "land of theory" unless you really do have third parties using your API.
Cheers!
Thanks for your answer once more. For now I'll just call the createToken action when registering a user and return the new token in the response. And then create a login request that with basic auth returns the token. Should be able to go far enough with that alone... still don't know how the js app works so I can always come back to the API :p
I'll leave OAuth for my next crappy app...
http://stackoverflow.com/qu...
Would it be possible sometime please do the same with Symfony2 and FOSRestBundle and other bundles maybe?
Definitely - I'll do exactly that! And we'll be able to move a little bit faster through those, because we'll have all the concepts covered here.
Cheers!
well, damn it, 3 days to get the security part to work on my project, I had reformulated my question here so many times that now I feel I still need to say something! I still don't understand some parts but hey, I got that going for me!
"Houston: no signs of life"
Start the conversation!