Allow integration with other Member types

[brendo]

The goal of the Members extension, and it's Member interface is to allow other Member types to be created by extension developers that can handle at minimum the Login and Logout of Members (for example, OAuth, Facebook etc).

At the moment this is not possible as the extension driver will always intialise the SymphonyMember type. Somehow this needs to change (probably a delegate) so that other members types can 'activate' themselves (ie. Facebook sends a $_GET['signed_request], so a Facebook implementation might look for that parameter to see if it's required to do work).

Additionally, the checkFrontendPagePermissions function is fairly hardcoded to expecting $_REQUEST['member-action']['login'] to trigger the 'login' logic. This needs to be abstracted in a similar fashion.

The Members extension currently provides an Identity class, with the idea that any new Member types extend this class to create a field that stores their identifying factor (eg. FacebookID). I believe this is mostly OK and will work as expected, but it should be reviewed as well.

/cc @remie @bauhouse

[designermonkey]

If anyone would like any oAuth assistance, I am available for weddings and Bah-mitzvah's.

[brendo]

Thanks ;)

It might be worthwhile asking, how does Twitter do the authentication? From memory they send some information back to an authorise URL?

[designermonkey]

Yeah, oAuth is about registering for an access token, then exchanging that token for an authorised token when a user goes to the app and adds their consent for your access token, it's quite technical, but also very simple at the same time.

The only problem is the fact that the site/developer must have an 'application' registered at the Auth end (Twitter, Facebook), and developers invariably forget this step. It's not a simple 'click here' setup.

[brendo]

That's the step that is infuriating while building an app on a development server. Facebook have taken steps to make it a little easier with their Test User simulation, but AFAIK Twitter are still a bit painful.

So there's two steps then (for Twitter?):

• developer authorises the App (aka Symphony) with Twitter
• members authorise with Twitter to use the App

[designermonkey]

No, you have to be on the Twitter site to create the app for your site. That's the irritating bit about it. Once that's done, the details need saving in your Symphony prefs (as with the Notifier).

Once that's done, then yes, Members could authorise using some logic, which directs them out to Twitter and returns too. That's what was the hard bit for e with the Notifier.

[brendo]

Yeah, that's what I've been working against for awhile now as there is a couple of ways it can be done. You can do the authorisation completely with PHP using the Facebook SDK, or you can 'nicely' do it with the JS SDK that then talks to the PHP SDK.

At the moment I have Facebook integration with Members just by passing the Facebook ID through to the Member: Username field, but it's not what I'd call integration. It's more like 'making it work ffs'.

I don't think Members should be responsible for initialising the 'hey go auth with Twitter/Facebook/Github', but I think it should be able to recognise the parameters that are sent back from these providers and create the Member (or log them in) using them.

Agree?

[designermonkey]

Yeah definitely, we would be just bloating the extension to add someone else's auth methods in there.

I think maybe we have some libs that accept the data and alter it into a standard set for our extension, that way they can be added to and altered if necessary.

[brendo]

Well we won't be adding anything to this extension, other than the ability for it to happen. Ideally other extensions would be created, 'FacebookMember', 'TwitterMember' etc, that provide the logic for that Member.

[designermonkey]

Sorry, yes, makes sense.

[remie]

Sounds like a blast :D how do you want to approach this?
Should we all start on our own branch and check which implementation is best? Or do you want to coordinate it?

[designermonkey]

OOh, look what I found! http://www.php.net/manual/en/book.oauth.php

[brendo]

how do you want to approach this? Should we all start on our own branch and check which implementation is best? Or do you want to coordinate it?

Good question! At the moment I have a couple of ideas but nothing solid enough to lead an implementation, so at this stage I think it's open for the interested to fork and experiment around with some ideas. Between us we'll nail the best implementation for all :)

I do however feel that this issues depends a bit #174, as at the moment it's not very intuitive to load additional fields that member's needs to be aware about.

OOh, look what I found!

Neat, didn't even know it existed. Looks to be fairly new considering the documentation is sparse. I think this may benefit the extensions more than Members though

[remie]

OOh, look what I found! http://www.php.net/manual/en/book.oauth.php

Look promising, but I did notice it has a dependency on PECL OAuth library. This might not be available on every host, so it would be good to also have an alternative ready that uses PECL Http / Curl.

[brendo]

Since Members 1.2, there is a delegate InitialiseMember that is fired as soon as the extension is enabled on the Frontend. It passes a single parameter, Member, by reference which can be populated with a new Member class by an extension. If this parameter is null, then the default SymphonyMember class will be initialised.

This should allow things like TwitterMember etc. as long as they have implemented the Member interface. The only gotcha at the moment is that the autoloader looks in the /lib folder for such implementations. On integration the autoloader is done using the spl_autoload_register, which theoretically means that your extension could also add to the autoload queue to tell the Members extension to allow look in location x for Member classes. For immediate use, the extension could copy it's file into this location, but that's really bad and pretend I never said it ;)

So in other words, I think this is now possible!