Skip to:
Content
Pages
Categories
Search
Top
Bottom

RPX + BuddyPress, what technical obstacles should we be aware of?

  • Avatar of Tracedef
    tracedef
    Participant

    @tracedef

    We’re seriously considering adding https://rpxnow.com/how_it_works to our checkout process when we launch. This would enable us to have users checkout of our cart while simultaneously creating an account with our billing and support software, creating an account on our MU install #1 where we build and host the client’s website and creating an account on our MU install #2 where our Buddypress / bppress install lives, so clients can access the community and forums.

    Any feedback on any technical obstacles or issues we might need to be aware of appreciated if you have experience with RPX / Buddypress! Thanks.

Viewing 14 replies - 1 through 14 (of 14 total)
  • Avatar of wpmubp.org
    wpmubp
    Participant

    @takuya

    Just make it buddypress plugin, so users won’t have to visit wp-admin/profile.php to change which IDs they use. If this setting can be done on frontend, it would be perfect.

    Avatar of Tracedef
    tracedef
    Participant

    @tracedef

    Thanks for the heads up. I’m guessing that’s going to be one of a handful of considerations we’ll have to account for when implementing for buddypress.

    Avatar of Gpo1
    gpo1
    Participant

    @gpo1

    We need this has a buddypress plugin?

    Avatar of John James Jacoby
    John James Jacoby
    Keymaster

    @johnjamesjacoby

    Everyone is always very quick to advertise the benefits of a single-sign on service, or a go-between to allow users to sign into your website using any number of different credentials, but there are a few major flaws with this idea, and they are going to become extremely apparent very soon.

    The first MAJOR flaw I see in this design, is that all it takes is one website to put up password stealing/sniffing code, and now you’ve given your twitter password to anyone with access to the sites malicious intentions.

    The second MAJOR flaw I see from a developers standpoint is that you as a site administrator no longer have control over the user data that is using your website. This means tracking down a problem user that creates an account with their facebook, you ban them, their google, you ban them, their open_id, you ban them, etc… That, along with the fact that these user registrations tend to add their own cryptic names into your database fields; now you’re forced to try to know who “fb8288373″ really is, when had they registered the normal way, you could see they are “johnjamesjacoby.”

    From a user perspective, I don’t plan on using Facebook for the rest of my life, so when I delete my account in a few years, that means I can no longer use your site without creating a new profile.

    Also, if I’m logged into facebook on my computer, and close facebook, and then my girlfriend walks over to a site and clicks on facebook connect and continue, it logs her in as me because I am still logged into facebook. Now I’ve registered at a website that I didn’t want to register at, and I have no way to delete that account, and who knows what kind of information they’ve decided to store about me by this point…

    Quite frankly, I can’t wait for this trend to die. It’s a headache waiting to turn into a brain tumor in my opinion. :)

    Avatar of wpmubp.org
    wpmubp
    Participant

    @takuya

    Also, if I’m logged into facebook on my computer, and close facebook,

    You tech genius wouldn’t do that, right? :)

    Avatar of Tracedef
    tracedef
    Participant

    @tracedef

    To clarify, this is something we’re going to be using for paying clients, not the public at large, so that should take some of the issues raised above out of the equation.

    Also, this is going to enable us to take away the 4 separate passwords / logins our paying customers need to use currently down to 2 for things like the forums, their website, billing, support, etc…. that is the main reason we’re implementing this…. otherwise we wouldn’t waste our time building something unless it was totally necessary….

    I’m not concerned about whether or not it is a trend as RPX has been getting serious traction and even some big box retailers have started using it, so unless it crashes and burns, I’m not worried. If it gets us by for a year or two, I would be happy with that too. :)

    Avatar of Gpo1
    gpo1
    Participant

    @gpo1

    @Tracedef, Are you starting the plugin or what?

    Avatar of Tracedef
    tracedef
    Participant

    @tracedef

    @GPo1: There’s already a plugin but it doesn’t seem to be ported to Buddypress yet…. not clear on how much work will take to do so….. I’ve heard it works as is, but there are some issues with the fields that you may want required being bypassed and other minor field issues as it is only meant to work with MU….

    Avatar of Arx Poetica
    Arx Poetica
    Participant

    @arxpoetica

    Just to address JohnJamesJacoby’s first concern, that’s not how OpenID works. “Sniffing” ain’t allowed. Authentication takes place *not* on the new site, but on the old site, i.e., Google or Facebook, and the *only* thing the new site is getting in terms of authentication is an oAuth token saying “Google says you’re good, so I’m going to authenticate you, using Google’s token and whatever other information you and Google have chosen to give me.”

    That means the new site gets NO password.

    ZERO.

    ZILCH.

    Now porting other data, and concerns over privacy with regards to that? Well, it’s not using Google or Facebook’s data, it’s *porting* it, so, yes, I can see privacy concerns cropping up all over the place with that, and it is a little Wild West right now.

    But that will get better over time. Somebody will think of a way to better secure your data, etc.

    Incidentally the OLD way for porting data *did* have the new site capture your password, i.e., to import friends on Facebook, you had to enter your email and password for, say, gmail, and then trust that Facebook wouldn’t keep it but would only scrape the data from gmail *one time*…THAT is dangerous, and, thankfully, OpenID and oAuth (distributed social networking) is doing away with that bad practice.

    To clarify, this is something we’re going to be using for paying clients, not the public at large, so that should take some of the issues raised above out of the equation.

    If anything, that alone would make me want to stay away from OpenID.

    Don’t get me wrong, I think it’s great for newspaper sites etc where someone can log in to comment. But if I’m paying you money, I want YOU to be responsible for any data I send you, and only you.

    Also, this is going to enable us to take away the 4 separate passwords / logins our paying customers need to use currently down to 2 for things like the forums, their website, billing, support, etc…. that is the main reason we’re implementing this…. otherwise we wouldn’t waste our time building something unless it was totally necessary….

    Sensible and laudable. How come you can’t have one for all four and self-host it? (Honestly curious here!)

    Also, if I’m logged into facebook on my computer, and close facebook

    You tech genius wouldn’t do that, right? :)

    I do this all the time. 99.99999% of the time, no one but me uses my computer. Once in a while, a guest comes over and looks something up, but it’s rare. But yeah, this is something most of us do. I never log out of sites when I’m using my computer, logged in as my user name. :)

    Avatar of Arx Poetica
    Arx Poetica
    Participant

    @arxpoetica

    Regarding who is responsible for data, it seems there is a lot of misunderstanding about OpenID out there. I’m not the ultimate evangelist on all this, but 90% of these types of concerns have already been addressed by the real know-hows of distributed social networking.

    OpenID does *not* mean everyone has access to everything. Rather, it just becomes a viable way to port information, when necessary or desired, more easily, as well as providing a way for an individual to be identified more easily at any given site — but, again, this doesn’t preclude telling every site everything. Trust is still a site by site variable.

    Here’s a list of great reads (plus a web “TV” show!) for those interested in understanding what’s true and what isn’t:

    http://factoryjoe.com/blog/page/12/ (old, but addresses some common concerns)

    http://josephsmarr.com/2008/04/23/data-portability-privacy-and-the-emergence-of-the-social-web-web-20-expo/ (also old, but an original “diso” reference”)

    http://www.sociallipstick.com/2009/03/a-proposal-for-a-conceptual-open-stack/ (social stack reworked)

    http://factoryjoe.com/blog/2009/02/13/this-week-in-video-facebook-and-the-openid-design-workshop/ (a bunch of videos from the OpenID Summit)

    http://thesocialweb.tv/ (periodic episodes updating the latest in diso)

    The final thing I would add is, like it or not, distributed social networking (OpenID and the like) are _already_ here: Google, Facebook, Yahoo!, AOL, MySpace, and a host of other providers have already embraced OpenID, and the clock can’t be turned back. There are still a lot of variables to be worked out (such as “single sign out”!), but BuddyPress would do well to support it, if not because it is a highly useful technology, then at least to support the percentage of customers who are going to want (demand?) the technology.

    Anyway, back to RPX and BuddyPress…

    Avatar of Gpo1
    gpo1
    Participant

    @gpo1

    Any update on this?

    Avatar of philipashlock
    philipashlock
    Member

    @philipashlock

    The first MAJOR flaw I see in this design, is that all it takes is one website to put up password stealing/sniffing code, and now you’ve given your twitter password to anyone with access to the sites malicious intentions.

    OpenID and oAuth were designed very much to prevent the spreading or co-opting of passwords. Until recently many services like Twitter let other services accept their user passwords, but now oAuth routes authorization requests to the appropriate authority.

    The second MAJOR flaw I see from a developers standpoint is that you as a site administrator no longer have control over the user data that is using your website.

    I don’t really follow this, but I also don’t think he’s describing the situation very accurately.

    I don’t plan on using Facebook for the rest of my life, so when I delete my account in a few years, that means I can no longer use your site without creating a new profile.

    This is no different than, “what if I cancel my email account”

    The nice thing about OpenID is that most good implementations will allow multiple ways of accessing the account (either multiple OpenIDs or the option of logging in with the native account username/email)

    Also, if I’m logged into facebook on my computer, and close facebook, and then my girlfriend walks over

    This isn’t unique to single-sign on services. Any time you fail to log-out of an account and give access to someone else, your account can be compromised.

    Avatar of Gpo1
    gpo1
    Participant

    @gpo1

    @philipashlock,

    here,here on your comments I plan to use openid and wordpress should use it !

Viewing 14 replies - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.