Closed (won't fix)
Project:
Simple FB Connect
Version:
8.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
4 Dec 2014 at 13:16 UTC
Updated:
24 Aug 2016 at 17:21 UTC
Jump to comment: Most recent
Comments
Comment #1
func0der commentedI see, that the patch includes the saving of the Facebook user id and the separation of the registration with a Facebook account.
This is a pretty good idea, because it is easier to register users coming from an API.
Thanks for the work.
Comment #2
masipila commentedThe 2.x branch of this module has been refactored so that the code is divided into manageable pieces.
See also #2386041: Documentation is needed about difference between 1.x or 2.x branch for further discussion on different branches.
Cheers,
Markus
Comment #3
func0der commentedSame here: Since 2.x is not going to be stable anytime soon, this should be merged in 1.x.
Comment #5
masipila commentedFix committed to 7.x-2.x-dev. Many thanks bellhof for the patch, I made minor updates to port your patch to 7.x-2.x branch.
7.x-2.x-beta1 will be released soon. If you want to test 7.x-2.x-dev, note that it uses Facebook PHP SDK v4 instead of v3 like 7.x-1.x. Also remember to run update.php so that the new database column will be created.
Cheers,
Markus
Comment #7
masipila commentedI reverted the commit which introduced the capability to store FBID after discussing this feature with the other module maintainer saitanay. We concluded that we want to keep this module as simple as possible and the matching by email address is sufficient for this simple module.
This design decision means that if the user changes her email address to her Facebook profile and then logs back to the Drupal site, a new Drupal user account will be created. Avoiding this corner case would mean storing the FBID to our Drupal database and altering the database schema. That is technically doable, but we concluded with saitanay that it is better to refrain from modifying the database schema.
Markus
Comment #8
func0der commentedThen I declare you module from now on as broken.
That philosophy is plain wrong.
Attached user data to an account like posts or favourites or subscriptions or whatever would be gone as soon as the user decides to change the Facebook email address.
If you do not want to alter the database schema, which is totally fine by the way, because it is not non-inversive, then create a new table that is responsible for the matching.
Do you really favour simplicity over correct and consistent behaviour here?
Comment #9
saitanay commentedhi func0der,
There are amazing modules like https://www.drupal.org/project/fbconnect and https://www.drupal.org/project/hybridauth available if you are considering any sophisticated integrations.
This module has always tried to remain as simple as possible, with a plug-and-play approach that you can switch on or switch off without affecting any other social integration or customizations you already have wrt user login or registration. The module also tries not to make any changes to the database.
I agree that the rare scenario of changing email address on facebook is not handled by the module.
The expected behaviour when you change your facebook email address by this module:
1) The user will fail to login with a clear message that no matching email address was found (I believe we display such a message already. We can if it's not already)
2) The user should login via drupal (either using the password, or by using the "Forgot Password" option and update his email address accordingly on the Drupal Site.
People rarely change their facebook email address and to favor the simplicity of this module, we had to take an informed decision to not handle this scenario.
Thank you
Tanay
Comment #10
kopeboyI think the Facebook user ID is much more useful than in that corner-case scenario.
What if I want to provide direct links to message a Drupal user on Facebook..
I mean, after connecting with FB, having the user identification from Facebook is something I would expect! No more, but at least that.
Also, keep in mind that fbconnect module has only 1.5k reported installs after 250k downloads! Clearly there is something wrong there..
Comment #11
masipila commentedRegarding messaging link (and tons of other use cases): you would definitely need a separate module for that functionality. That module can easily implement the hook provided by Simple FB Connect and store the ID. This is exactly why we provide an API for other modules so that it is easy to extend the integrations to FB exactly how you want. See https://www.drupal.org/node/2475401 and https://www.drupal.org/node/2475445
Regarding fbconnect module: that module is deprecated in many ways, I do not recommend using it.
Cheers,
Markus
Comment #12
masipila commentedChanging the status back to wontfix
Comment #13
toemaz commentedFor those are in need for a D8 auth solution using fb id rather than the email, add your voice in social_auth_facebook https://www.drupal.org/node/2788605#comment-11540915
Comment #14
swentel commentedFor anyone hacking on the D8 version, here's a way to use the facebook id as canonical to login, you don't need to hack in the module at all. I still think this should be the way to go as well, and it's also dead easy todo.
Add a facebook_id base field.
In a RouteSubscriber, take over the controller.
The Controller looks like this, the part that is different is were we pass on the facebook_id in the createUser method, or load by facebook_id instead of email.
In a service provicer, switch the user manager
That manager looks like this
Comment #15
masipila commentedIt is much simpler to just add a listener to the FB login / FB user creation events and add your custom code there.
The module handbook has a working example for adding a role to the user. That example can be used as a basis for modifying other user fields.
https://www.drupal.org/node/2643016
Cheers,
Markus
Comment #16
swentel commented@masipila not if you want to use the facebook id as the canonical to login, instead of email. We're missing an event there in the controller - or something else. Some pseudo code to explain the problem
Now, I probably don't need to take over the create user method, since I can probably just implement hook_user_presave(), but a hook there to alter the user object that you are creating before it's saved would be very handy as well.
That would save tons of overrides here :)
Comment #17
masipila commentedHi,
Thanks for the clarification! The concept for dispatching a new symfony event before the user is saved is ok to me but please open a new issue for that purpose.
Patches are also more than welcome (to the new issue concentrating on the new event) because my own time is extremly tight at the moment. And let's use event dispatching instead of traditional hooks so that the event is also automatically available for Rules without any extra effort.
Cheers,
Markus