Search

Hi Jonathan, thanks for the reply! 1° way: do you have an example of the membership class for handling oAuth? I read on about it, but I can't understand how I can implement it. At first I would like to try without the switch, and try to add it later.. 2° way: I've seen and tried your oAuth extension (and also facebook toolkit extension), and I get it working on the last version of Symphony (2.6.2), but what I can't understand now is how to relate the logged user (oAuth login) with the registration/login of a member account. I thought it could be possible triggering some events with js/angular, but I don't understand if this is a secure way or not. Is it?

Ps, if you have an example also for the second way, that would be great! :) Thanks

Hi Dave, very sorry for the delayed reply, I was heading off for WebSummit and kind of lost track of things.

  1. No I don't have an example of handling membership extension with oAuth. I did have one with a 3rd party confidential API which I cannot share. But if you still need this would be happy to look into it time permitting.

  2. Yes you can theoretically do that, If you're using js/angular the easiest way would be the following. Get the oAuth going, once the user is authenticated with oAuth, take his details and register a user with the same details, for a password you can do a random hash for security reasons, the user will never really log in with a password if they use social. In case the user exists you can look up via the email address and if not mistaken the members class has a php function you could use to force a user to log in using simply their email address or user id. It might need you to slightly hack the event php code for login/registration via oAuth. No examples here either I didn't go that far as of yet.

If you need a quick response, I'm usually around on gitter, or drop me a tweet on @jonmifsud and I'll be right on it.

Continuing the discussion from here, as it is more relevant to the Members extension.

Re: Email verification upon email change

Thanks a lot for your thoughts, Michael. I agree, there is no 100% secure approach to make sure an email address is not fake.

The fake address is not the only consideration, though. A member might try putting someone else's address and if that someone receives an email there is a good chance they will mark it as spam, which I want to avoid.

Also, I want to reduce to a minimum the number of fraudulent accounts a user creates. The website I need this for holds a contest with prizes and the number of votes determines winners. Each member can vote once.

Yes, they can have many email addresses but unless I implement some sort of verification they would be able to create many accounts using a single email address for activation and then changing to any email address they want, and subsequently freeing up the "good" address for a new registration.

Indeed, the reactivated member gets the default role. In my case it isn't an issue but it wouldn't be acceptable. [Edit: Not true, looks like the extension remembers their role!]

I like a lot how the password field works - user gets logged out only if the password has been changed. Maybe the email field could work in a similar fashion - if email gets changed the member is assigned an "Unverified" role temporarily (with a code generated) and they get back to their normal role only after verification.

It would be a great feature for this extension because the out of the box setup takes away all the benefit of the initial activation.

Sorry, @ellie, I admit that it would be nice addition to be able to verify email addresses on change — but I have no idea how to implement it, nor would I find the time to do it.

A good verification key would be the combination of fingerprintjs2 and visitors IP. If both are matched with an existing member account it s likely a fake new member. Members can have multiple fingerprints (depending on their device) as well as multiple IP (for the same reason). So it can be a real challenge to implement.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details