Closed (fixed)
Project:
Social Auth
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
25 Oct 2016 at 00:22 UTC
Updated:
4 Mar 2017 at 13:44 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
denutkarsh commentedI'd like to provide the patch for this issue.
Comment #3
denutkarsh commentedComment #4
denutkarsh commentedIMHO we could easily implement these features in authenticateUser() method #2848144: Create authenticate method. Since the patch hasn't been committed for that issue till now, so i think currently this patch is of no use. Indents still nodes to be fixed on needs line and i haven't implemented "Disable Login Role" feature. Anyways, i am think of something like this.
Comment #5
denutkarsh commentedHere is the patch. Tested it with "Social Auth Twitter", it works correctly.
Comment #6
denutkarsh commentedHere is the patch. Tested it with "Social Auth Twitter", it works correctly.
Comment #7
denutkarsh commentedOops, forgot to correct route path. Here is the new patch.
Edit: Patch name is not right because of the confusing between the comment number.
Comment #8
denutkarsh commentedForgot to implement "Post login path". Here is the new patch, which all contains the fix for a bug for "Disabled Roles".
Comment #9
gvsoThanks!
I'd prefer this logic to be place in a different method. Thus, implementers which do not use the authenticateUser method can check this setting. Also, use drupal_set_message to let the user knows why he couldn't log in.
Same as above.
Same here. Plus, I think if the new created user is not redirected to the edit form, it should be redirected to post_login_path
Comment #10
denutkarsh commentedHere is the new patch.
Comment #11
denutkarsh commentedHere is the new patch, which redirect to route if it exists or else it just redirects to path.
Comment #12
gvsoThis looks better, but I have a few suggestions.
I think it is better if this methods return TRUE/FALSE values. First, it would allow implementers which don't use the authenticateUser method to provide their own messages/functionality. Second, you avoid the assignment operation inside the if clause
'..for Admin (user 1).'
'.. is disabled.'
Comment #13
gvsoHere's a new patch for this issue.
Comment #14
denutkarsh commented@gvso The new patch, looks good to me. But should we follow the first suggestion in #12 since we have already removed the assignment operation inside the if clause ?
Comment #15
gvsoWhat do you mean by following the first suggestion?
Comment #16
denutkarsh commentedRTBC, didn't noticed that you are following the first suggestion i.e you are returning TRUE/FALSE values.
Comment #18
denutkarsh commentedThanks! I've committed it on 8.x-1.x
Comment #19
denutkarsh commented