Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification for use of CreateFreshApiToken middleware #19

Closed
elynnaie opened this issue Aug 18, 2016 · 3 comments
Closed

Clarification for use of CreateFreshApiToken middleware #19

elynnaie opened this issue Aug 18, 2016 · 3 comments

Comments

@elynnaie
Copy link

Based on my reading of the code and the docs, it seems that, in order to make use of the CreateFreshApiToken middleware, the user must first authenticate with a GET request, at which point the middleware kicks in and sends the cookie back with the response. Does this mean that, for my own JS application utilizing my API, I would have a special API endpoint that does auth the old-fashioned way (e.g., username/password), and then this middleware would take over authorization from that point, and the rest of my endpoints can pretend like the user was authenticated through OAuth?

If so, ordinarily I would design my login endpoint to use a POST, but the code seems to only create the cookie on a GET. Does that mean that my login endpoint has to use a GET in order for this middleware to work, or am I misunderstanding the intent?

@townfolio
Copy link

townfolio commented Aug 18, 2016

@denaje The way it works is that you need to have an authenticated user that was logged in via a call to Auth::login (or one of the alternatives). That can happen on a post back to the server (usually the login form) and then when you get redirected back to a GET request, Passport will check if the response & request should receive a fresh token.

The way it determines that is by checking first if the request is a GET request (remember this could be your redirect or just a new page) and that the request has an authenticated user (via $request->user() in this case). Next it checks if the response is an instance of Illuminate\Http\Response & that it doesn't already contain a token. The token in this case being the cookie with the name of laravel_token.

So if all of that passes, the cookie will be attached to your response. At that point you can make requests to your API using that cookie and a CSRF token (assuming you've followed the setup mentioned in the docs.

So the way that works then is by starting off with a CSRF token you can grab with your Javascript. In the docs they show this code (using Vue and Vue-Resource).

Vue.http.interceptors.push((request, next) => {
    request.headers['X-CSRF-TOKEN'] = Laravel.csrfToken;

    next();
});

Now that Laravel object is actually something you create in your view (probably your master view), like the following.

window.Laravel = {
    csrfToken: "{{ csrf_token() }}"
};

Now assuming that your API is on the same domain (and not a subdomain), you will be good to go. There is additional setup if it is on a subdomain, but I won't get into it as this is getting quite wordy.

@elynnaie
Copy link
Author

Excellent, thanks for the info. I would be interested in discussion about how to set it up on a subdomain, but that doesn't have to be here or now. In the past, I attempted to do it by setting up CORS middleware (which worked), but the cookie being sent back in the response didn't get "saved" by the browser and sent with future requests, even though everything I could find on the internet seemed to indicate that it should. I ended up writing an http interceptor to manually send headers instead, but a cookie solution would be nicer, if that is even possible.

@GinoPane
Copy link

Does anyone know which scopes would be granted for that token?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants