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

Stateless #68

Merged
merged 5 commits into from May 11, 2015
Merged

Stateless #68

merged 5 commits into from May 11, 2015

Conversation

isaackearl
Copy link
Contributor

@isaackearl isaackearl commented Apr 23, 2015

I'm working on a project that is an API, which utilizes JWT tokens, and is stateless.

Having a stateless option would very nice so that I can use socialite without utilizing the session. I've made some modifications to have it check if the stateless flag has been set. By default it acts exactly as it did before so this change will not affect any current users.

it can be used like this for the redirect:

return Socialize::with($provider)->stateless()->redirect();

and like this for the user:

$provider_user = Socialize::with($provider)->stateless()->user();

of course it can still be used in conjuction with scopes etc

 return Socialize::with($provider)
                ->stateless()
                ->scopes(['email'])
                ->redirect();

The main use case is if somebody is doing the redirect (authorization) portion using a frontend client like angular etc. Then they want to be able to make a request to the backend and get the user... so in that case the redirect() function would never be used and a stateless option is needed for the user() function.

If you don't like it please let me know if there is another approach I could take that might get accepted.

@@ -3,3 +3,4 @@ composer.phar
composer.lock
.DS_Store
Thumbs.db
.idea
Copy link
Member

@GrahamCampbell GrahamCampbell Apr 23, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no

@isaackearl
Copy link
Contributor Author

@isaackearl isaackearl commented Apr 30, 2015

Let me know if there is anything else I could improve upon, or if there is another approach you want me to take to solve this problem.

@GrahamCampbell
Copy link
Member

@GrahamCampbell GrahamCampbell commented Apr 30, 2015

This should probably go to 3.0, not 2.0.

@isaackearl
Copy link
Contributor Author

@isaackearl isaackearl commented May 1, 2015

Hey Graham, Sorry for being a noob but I'm hoping you can give me a bit of direction. After pulling in the master branch, it seems as though the 2.0 version is actually ahead of the 3.0 version by a few commits. I was going to close this pull request and add something similar to 3.0, but I think it would cause some merging conflicts when it comes time to merge. Shall I leave this here for now? Thanks.

@taylorotwell taylorotwell merged commit d44432c into laravel:2.0 May 11, 2015
1 check passed
tremby
Copy link

@tremby tremby commented on 44e8164 Apr 14, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there security implications to not checking OAuth state?

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

Successfully merging this pull request may close these issues.

None yet

4 participants