As reported by user cerup here (complaint #2): #668434: Beta 10 issues (almost same as beta 9)

Consider the following scenario:

1) new user logs into Gigya via Facebook

2) is presented with a page to finalize registration on Drupal

3) fails to complete registration for some reason

4) returns to the site at some point in the future and this time logs in via Twitter

5) this time they complete Drupal registration

6) This user will not be able to connect their new account to Facebook because the Facebook user is considered to already have an account on the site

As soon as you log into Gigya via a social network Gigya considers you a "site user"; even if you don't complete the Drupal registration, and even though the Drupal site never called socialize.linkAccounts() or socialize.notifyLogin() (frankly, I think the API should change to only consider you a site user if you've called one of those methods). The only way to "free up" that social network account would be to call socialize.unlinkAccounts() for any Gigya users who didn't complete the site registration. I'm thinking the best way to do this will be to record in the DB all unregistered users who hit the /socialize-login page after a successful Gigya login. If a user creates an account they're removed from the table or otherwise marked as having created an account. gigya_cron() could run unlinkAccounts() on all old records in the db that never got registered (after a certain period of time like a couple of hours or so).

We'll need to decide what DB structure this module should have as we move towards beta-11. My patch here #647334: Gigya user registration form override causes issues w/Organic Groups, User Location, Legal, LoginToboggan completely obviates the need for the gigya db table. That said, I think there's some merit to keeping a gigya db table of some sort; for this problem and possibly to implement other features (though I'm not sure what those would be at this point). But that's probably a discussion for another thread.

Comments

EvanDonovan’s picture

EvanDonovan commented
Version: 6.x-1.0-beta10 » 6.x-2.0
Status: Active » Postponed

This still happens in 2.0, but marking as postponed for now on #742430: Patch to fix several bugs.

EvanDonovan’s picture

EvanDonovan commented
Version: 6.x-2.0 » 6.x-2.1
Status: Postponed » Postponed (maintainer needs more info)

Does this still happen in 2.0/2.1? I am not actually sure...

azinck’s picture

azinck commented

Yes, this is still a problem.

azinck’s picture

azinck commented
Status: Postponed (maintainer needs more info) » Active
EvanDonovan’s picture

EvanDonovan commented

I have emailed Gigya about this. It happens in our JSP implementation as well. Will update with more info, when I have it.

azinck’s picture

azinck commented

Yeah, it's basically an API "problem".

EvanDonovan’s picture

EvanDonovan commented

@azinck:

Here was my most recent email response from Gigya in regard to this issue:

"It sounds like the linkAccounts() call needs to be made at the very end of the registration process...this seems like more of a Drupal-specific issue."

However, I confirmed with my co-worker that she doesn't call linkAccounts() on the page that does our user registration or linking on the JSP site, http://www.christianvolunteering.org (which also uses the JS API). The only thing we call is the Socialize showLoginUI JS method for the user login on the JSP site's homepage. So I don't think that Gigya's reply actually identifies the cause of this bug.

Would the bug be resolved though, if a call were made to unlinkAccounts() if someone left the register/link page without completing the form. And, if so, how would that work?

EvanDonovan’s picture

EvanDonovan commented

On April 7, 2010, this was confirmed by Gigya's internal QA as a bug and they are looking into it.

Copying the exchange with Gigya into this issue:

From Aaron Zinck:

Hi Itamar (and others),

I did a lot of testing at the time I filed that bug (http://drupal.org/node/678576) and what I wrote still stands. Unfortunately gigya considers a user a "site user" ( isSiteUser == true in the Gigya user object) as soon as they've successfully authenticated via Gigya. No linkAccounts or notifyLogin call is needed. Once Gigya considers a user a "site user" that gigya account cannot be added to another Gigya account via the editConnectionsUI without running unlinkAccounts.

From Itamar Novick:

Just a note about isSiteUser - This field is used to indicate whether a friend has logged-in to the site using Gigya.
I guess the field you wanted to address is isSiteUID, which indicates whether the user has a siteUID assigned to it.

I can verify that we have an issue with this scenario (I consider it a bug) and we will start working on fixing it to behave like you envisioned at the first place.

Thanks!
Itamar.

azinck’s picture

azinck commented
Status: Active » Postponed (maintainer needs more info)

Waiting on info from Gigya...

azinck’s picture

azinck commented

Woot! Gigya has updated their API so that this problem can be circumvented. Just checked a fix into dev.

azinck’s picture

azinck commented
Status: Postponed (maintainer needs more info) » Fixed
azinck’s picture

azinck commented
Version: 6.x-2.1 » 6.x-3.x-dev

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.