[wp-hackers] Single sign-on with Wordpress & Mediawiki
wp-hackers at striderweb.com
Mon Oct 29 18:34:10 GMT 2007
Check out the conversation in August with the subject "Sharing Users/
subject.html> -- search for Curt Woodard especially
Curt Woodard was working on a WP plugin that allowed simultaneous
login to multiple linked WordPress blogs. Not quite the same thing,
I was helping him out with testing and such, and one thing I
discovered is that, while user management in the WP code is
theoretically abstracted in a way that should make this easy, the
reality (that is, the code) is that the abstraction was not fully
implemented, and thus doesn't quite work for this type of thing.
I would have to dig up the WP core function again, but basically
there is a wrapper function (or two) relating to managing users that
isn't used -- other core code skips the wrapper and goes directly to
the main function. If it were wrapped properly, it would be fairly
easy for 3rd party plugins to modify the behavior without having to
recreate the primary functionality -- by replacing the wrapper.
Another issue, as discussed in that thread, is that WordPress stores
table name information in fields, which makes it a lot harder to
simply access the appropriate fields -- you also have to fill in
_other_ fields with the name of the field you want to reference!
On Oct 29, 2007, at 2:05 AM, Computer Guru wrote:
> Honestly, you could solve all this without any help/cooperation
> from other
> projects by simply writing a standalone authentication system.
> Users register/log-in at your custom script.
> This script is not a passive element that interfaces between
> multiple APIs
> in different projects, instead, this script has plugins that
> explain how
> user info is stored in MediaWiki, WordPress, vBulletin, etc. and it
> opens other tables, inserts user info in all of them, creates the
> needed cookies, and sets the user off on his or her way.
> Only problem is what happens when the user wants to change a
> password, edit
> an email, etc. and attempts to do so from within one of the
> projects instead
> of your centralized authentication system - then your info is out
> of sync
> and everything will be a mess. For stuff like wordpress with plenty
> of hooks
> and stuff you can easily add a plugin to WordPress that will update
> central auth system's info when a user changes stuff - but then
> that is no
> longer the "independant master auth" system at work.
> For user registration, a simple mod_rewrite directing everyone away
> /forums/login.php and /wordpress/wp-login.php to the central auth
> should do
> the trick.
> I currently have a gallery (Gallery2), blog (WordPress), forum
> bug tracker (JIRA), wiki (Confluence). and a couple other things
> tucked away
> on my site. When I first launched, I would've killed for this
> but that was a long time ago and I had no idea what any of this
> stuff was.
> Luckily for me, I ended up disabling user registration everywhere
> except the
> forums and the blog (where people can just write anonymously with
> existing forum usernames) so it's mosty a non-issue, i.e. no one is
> to log into multiple sites (but me!) so I can live with that.
> On 10/29/07, Jacob <wordpress at santosj.name> wrote:
>> Sneaks wrote:
>>>> Yep. Shouldn't know or care. Authentication is authentication. I'm
>>>> saying that there should be no "primary" web application -- all the
>>>> auth logic should be centralized behind a common API so that
>>>> logging in
>>>> in one place is *exactly the same* as logging in somewhere else
>>>> (within a single site).
>>> i'd also like to take this moment to again point out that there is a
>>> big difference between having one username to login to different
>>> of a site, and actually logging in one time for all parts of the
>>> most of this thread has just been about merging tabular user
>>> data, but
>>> my original question was about getting other applications in the
>>> site to recognize that a user was already authenticated inside
>>> application X.
>> Well, if you are talking about databases, then I think the issue
>> is more
>> that you won't get any project to develop a system where the
>> username/password is completely separate table from all other profile
>> information. Projects like phpBB (v2.x) have the entire username
>> password in one table.
>> However, I think the solution you are talking about and I think that
>> WordPress has (the code, I think has this capability, have to double
>> check) is referencing which table has the username/password and
>> what the
>> field name is of each. You don't really need to know about the
>> information (but it would be nice to not have to keep filling out the
>> damn information for each project).
>> There are several projects that do this already. However the
>> method for
>> which to let the project know is different. Most only give you a
>> function to use and call to sign the person in for that project.
>> However, all of these projects would have to be on the same server or
>> domain, but I'm most likely wrong about this depending on if my
>> about PHP cookie writing is correct.
More information about the wp-hackers