3

I have a lovely OAuth setup so people can use facebook to register for my force.com site.

It works great for new users, or for existing users where facebook email matches their account.

There's a field on the Auth Provider page called "Single Sign-On Initialization URL" that's used as the link for the registration button and the login button in the salesforce documentaiton.

But if someone clicks the Login button (custom login page) it's linking to the "Single Sign-On Initialization URL" from my Auth Provider.

What I'd like to do is return "no account found...would you like to create one?" What I'm trying to prevent is people trying to sign on with facebook who already have accounts UNDER A DIFFERENT EMAIL on my portal and then it creates a duplicate account for them.

By letting them know the account doesn't exist, they could know they need to login the old way and use that "link" option. Otherwise, they'll be wondering why that have to do new user setup, where all their data is, etc.

Here's the flow

1 Login via facebook/OAuth

2a If it's an existing user, login them in.

2b If it's a new user, direct them to the registration page. There, they can set up an account via facebook OAuth (what the login button is currently doing now). That way, if they know they have an account already, we can help them with linking it.

The only solution we have so far is to have the Registration handler prevent registration. But I only want it to prevent registration from the login page, not from the registration page.

6

This should work: If you don't want to create the user, then return null from createUser in your Registration Handler. That will cause an error to occur. You can configure a custom error URL for your Auth Provider, where we will redirect the user along with the error message. Make this a Sites page that looks at the error, and presents the user with a customized Self Registration page. When they are done with reg you could even put them back through the linking flow.

| improve this answer | |
  • Chuck, the ability to stop the flow under various conditions sounds promising. Could I then have two auth providers--one for the registration page where I would want accounts to be created and one from the login page that won't create accounts and only allows login? – Shane McLaughlin Sep 26 '13 at 19:02
  • 1
    You could but I don't totally follow. I guess the trick will be trying to figure out if they have an account with a different email, or don't have an account at all. You'll need to branch your behavior based on that, and it's likely what the registrion page woul need to ask the user. Probably can be handled with 1 auth provider though – user3953 Sep 26 '13 at 19:10
  • added some more explanation of why I need login and registration, but separate. – Shane McLaughlin Sep 26 '13 at 19:27
  • As Chuck noted, you can implement your registration handler and put whatever logic that you want into your createUser method. If you want to go and find an existing user based on some matching criteria and return that user instead of a new user, that's entirely possible. – greenstork Sep 26 '13 at 19:51
  • ended up going with the two handler scenario...see the accepted answer. – Shane McLaughlin Dec 27 '13 at 17:45
1

Our registration process (the site is mytruecost.com) is deeper than just identity--customers set up some additional custom objects, agree to the T&C/privacy policy, in the standard new customer flow.

Here's the solution I came up with for this:

First, create 2 auth providers: I called mine Facebook and FacebookLoginOnly.

In the class that is autogenerated, the "LoginOnly" should only have update calls, i.e. don't insert any users.

The link on the login page uses the login only auth provider, and the registration page uses the standard one.

The loginOnly has the error page set to a "new customer" page. So if you're trying to sign in with FB but your account doesn't exist already, we'll prompt you to register (which you can do with facebook) or link your existing account to your FB.

Here's the adjustments (this comes from the CreateUser method that's autogenerated). The goal is if there's not a match, then we don't make a user.

List<User> l = [SELECT Id FROM User WHERE UserName = :data.email];
        if (l.size() > 0) {
            u = l[0];
            System.debug('Found existing user record for '+data.username);

            // Update existing record
            u.Email = data.email;
            u.LastName = data.lastName; 
            u.FirstName = data.firstName;
            // Useful to save the Facebook ID in a custom field
            u.Facebook_ID__c = data.identifier;

            System.debug('Updating user record for '+data.username);

            update(u);
            return u;
        } else {
            return null;
        }
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.