Understanding People

aanand

Hello all. I'm loving the look of Vanilla and am very excited about getting it up and running, but my plans are a bit ambitious. I want to plug a couple of other applications (running on the same server, of course) into Vanilla's authentication system. I've been following the development of 0.9.3 and the claims that it should make this possible, and from looking at the code and Mark's comments I've gathered that a semi-separate application called "People" now manages user authentication. Thing is, I can't quite figure out how to utilise it from an external script. I can understand that as 0.9.3 hasn't even had a stable release yet there's little to no documentation, but I'd really appreciate some pointers with this. Thanks.

Jazzman

I think you only need to include the "init_people.php" from the appg folder... but I could be mistaken

aanand

I'd got that far, but didn't actually know how to check for a valid session.

After some playing around, though, I've got it. If anyone else wants a basic guide, here's my test code:

include("./vanilla/appg/settings.php");
include("./vanilla/appg/init_people.php");

if ($Context->Session->UserID) {
    echo "You are logged in as <b>{$Context->Session->User->Name}</b>.";
} else {
    echo "You are not logged in.";
}

NickE

You'd probably also want to include the user-configured settings as well.

aanand

You mean in /conf/settings.php? It's done automatically at the end of /appg/settings.php.

NickE

Oh. *smacks self in head. Stupid me.

Mark

People is actually a set of files and libraries that can be included in any project. What you see on the login screen, password reset/retrieval, and application form are all files that are a part of people. Of course the library/People* are also included, as are a large number of the library/Utility* files - which are all part of the lussumo development framework. The real magic of "People" is that you can write a custom authentication class and place it in people. So, if you have an existing application that relies on php sessions and/or cookies, you can change your authentication class to validate a user and save the proper values into the session and/or cookies. Alternately, the authenication class can be used to read existing values in a session or cookie which have come from your external application and perform whatever queries are necessary to figure out what the vanilla user is. If you take a look at the library/People.Authenticator.class.php file, you can start to get a good idea of how you might write your own version to handle user sessions. Sorry I can't go into more detail than that right now. Lots of work to be done.

aanand

Thanks for the clarification. I love the work you've done so far. I had hoped to convince Mediawiki and Wordpress to ask People if an authenticated session exists, but they're both pretty useless on that front (and their documentation is just awful). I'll probably have to do the ugly thing and fake the cookies / session values myself.

Minisweeper

Hmm. I'm making a tiny system for school so people can write messages for each other to go in the yearbook and it just occured to me i'm gonna have to deal with sessions and all that whatnot. Will people be really simple enough for me not to go to the bother or is it way overkill for something like this?

Mark

I don't think it's overkill at all. I mean, it allows you to create accounts, manage passwords, and sign a person in with remember me cookies if necessary. It can be attached to just about any database. It's everything you need to start a session-based system.

aanand

Agh, my worst fears have been realised. Including init_people in any other big application (e.g. in my case MediaWiki) results in all sorts of horrible name collisions and "cannot redefine class" errors. Does anyone know a way around this? I remember a while ago I circumvented it by writing a command-line PHP script that I exec()'d from another script (so they were running completely separately) but that's a very hacky method and besides, our server has since disabled exec() for security reasons.

Mark

Oh, well, the point of people is not to integrate it completely with another site. It's pages should be standalone. You install it and set it up so that it can set up sessions or cookies in a way that your other application can then pick up. In the case of Lussumo software, I continue to use it's classes throughout my other applications, but I don't need to. I could just as easily have my other applications get the session info and define the user.

aanand

Yeah, that's what I'd concluded. The approach you've chosen works fine if you haven't clicked "remember me", but if you have and you visit one of the other applications first, it'll think you're not logged in (because the session hasn't been set up yet), requiring you to visit the forum (allowing it to read your cookies and initiate the session) and then return. I'm trying to work around it by first checking for the session value (if it's there, everything is fine) and falling back to the People cookies. If the cookies are present but no session, I redirect to a People script which simply initialises (causing the session to be set up) and then redirects back.

Mark

Check out People.Class.Authenticator.php Everything you need for validating a user's cookies is in there.

aanand

Thanks.

(Haha did you know that MediaWiki likes to use its own separate session so you can't read session variables from anywhere else haha I am having so much fun.)

emiller

I've written a custom authenticator (it bounces passwords off an LDAP server), but I'm not sure if I'm enabling it correctly. In my settings.php, I set $Configuration["AUTHENTICATION_MODULE"], and I enabled the class like any other extension. However, there are a few problems. In the init_*.php files, this line:

$Context->ObjectFactory->SetReference("Authenticator", $Configuration["AUTHENTICATION_MODULE"]);

appears before

include($Configuration["APPLICATION_PATH"]."conf/extensions.php");

so I get an error saying it doesn't recognize my custom authenticator class. When I rearranged those two lines, I got another error because init_vanilla.php wasn't loading the Authenticator class before it loaded the extensions. So I added this line to init_vanilla.php:

include($Configuration["LIBRARY_PATH"]."People.Class.Authenticator.php");

Everything works now, but I wanted to know: are custom authenticators supposed to work like other extensions, or am I doing something wrong here?

Mark

Hi emiller, that's a great question, and I'm glad you asked it.

The Authenticator is not really supposed to work like other extensions for exactly the reason you identified (extensions are loaded after the authenticator class has been instantiated).

There isn't really any way to make it work as an extension because of the order of operations (the authenticator *needs* to be instantiated and working long before any extensions are loaded).

As always, I'm open to suggestions on the best way to handle this. My original idea was that you would just place your custom authenticator class in the library with the Utility.Class.Authenticor.php name (renaming the other one first, of course). But now that makes the

$Context->ObjectFactory->SetReference("Authenticator", $Configuration["AUTHENTICATION_MODULE"]);

line kind of useless, doesn't it?
Perhaps I should make the AUTHENTICATION_MODULE be the name of the file that contains the authenticator class instead.

I think that's what I'll do. Right now.

I'll post an update when it's ready in a few minutes.

Mark

Okay, so now the AUTHENTICATION_MODULE is defined like this:

$Configuration["AUTHENTICATION_MODULE"] = "People.Class.Authenticator.php";

And the SetReference line has been removed from all init files. Instead, the authenticator is hard-included in every init file like this:

include($Configuration["LIBRARY_PATH"].$Configuration["AUTHENTICATION_MODULE"]);

This, of course, means that you can make a new Authenticator class like Custom.Class.Authenticator.php. You must then place that file in the library and set the reference in your conf/settings.php file like:

$Configuration["AUTHENTICATION_MODULE"] = "Custom.Class.Authenticator.php";

And you're golden. Maybe not the best solution, but like I said - I'm open to suggestions.

emiller

I'll like this arrangement if I can inherit from Authenticator, but it looks like my authentication module must have the class name Authenticator. That would make it impossible to use a sub-class as an authentication module, correct? However, I think this would be a great place to define custom classes through inheritance, so that your changes to methods that I haven't touched are automatically used by my authenticator. For example, the way things are now, I'm just altering the Authenticate() method, but if you make improvements to cookie management in Authenticator.php, then I'll have to merge the improvements by hand. Especially if I'm going to be sharing my authenticator with other system administrators, I'd like not to have to worry about keeping all of the other methods up-to-date. Of course, if I can use an Authenticator sub-class, do tell...

emiller

I was thinking, maybe you could have a full-featured base class ("BaseAuthenticator") from which People.Class.Authenticator inherited trivially; then other Authenticator classes could also inherit from BaseAuthenticator, then over-ride methods as needed. That way, you'd take advantage of inheritance, but the code could rely on the fact (as I believe it does now) that the authentication module is called Authenticator.

glebis

I've been searching the forum, the docs, svn, googling around and so on, but I haven't found where I can get this magic lussumo development framework. No link at all. No link for People also. Where?