How is "People" supposed to work?

moe

Hi, I'd like to integrate vanilla with a website of mine (which is running java, maintains its own sessions and uses no SQL db). After a quick forum-search it seems the recommended way to do that would be "People". Okay, so I went and read the few threads on the subject and I also looked at http://lussumo.com/swell/42/Data-Objects-External-Application-Integration/ But.. I still don't get it. :( Can anyone explain to me how it's supposed to work? What do I have to setup on the vanilla side and on the remote application to allow my users to enter the vanilla forum without logging in again?

Bergamot

If you want to use your site's login and session management for your vanilla site (as opposed to the other way around), you need to rewrite chunks of People's authentication code.

Most of the threads you're reading are probably useless to you, since they mostly deal with using Vanilla sessions in other programs.

Minisweeper

Depends if he wants to do it the other way round though. He needs to decide that first really.

moe

Well, the most sane approach that I could imagine would be a simple "session migration" mechanism: 1. User clicks on the "forum"-link in my webapp 2. The forum-link points to a "trigger" URL (which is served by vanilla) and contains a single GET-parameter; the user's current webapp-session-id. 3. Vanilla receives this request and calls back (via HTTP) to a "pull"-URL (which is served by the webapp), appending the sessionid that it just received. Note: this callback happens between vanilla PHP and the webapp so the request is not exposed to the browser. 4. The "pull"-page on the webapp looks up the sessionid and if it's valid returns a chunk of XML to vanilla that contains all userdata that vanilla needs (i.e. all fields from vanilla's SQL user-table). 5. Vanilla checks if the user exists (via simple username lookup, no password check necessary, remember we're reading from a trusted URL!) and does one of two things: 6a. User doesn't exist; vanilla creates the user (using the data from the XML response) and then proceeds to 6b. 6b. User exists; vanilla creates a session (just as if the user had regularly logged in) and the user can now use the forum - without typing in his credentials again. This approach has the following advantages: - Easy integration. External authentication providers (my webapp in this case) can be added without changing any vanilla-code. All that needs to be added is the "pull" page on the remote end which should usually be a 5-minute job (create single jsp, php, rhtml, whatever page..). - Vanilla and "remote app" can live on different machines (share nothing). - Vanilla and "remote app" keep maintaining their own sessions and user-db. The mechanism just provides a one-way-sync towards vanilla. - Even multiple external auth providers could be added easily, vanilla need not care. Is "People" geared towards this direction? And if not: why not and when will you start? ;)

Mark

I've written something like that for a client who was using Vanilla. I did all of it without altering Vanilla's source code - I just made an add-on. You can do the same pretty easily.

People was written to provide a way to integrate Vanilla with any system by making configuration changes in Vanilla and *sharing* sessions.

There is not really any way for me to know what any given foreign application will require in order to integrate properly. So, the type of integration you are talking about needs to be a custom solution and doesn't really apply to People.

moe

Hm, cool! Is that extension around somewhere so I can use it as a template? I'm not familar with the vanilla code so I'd need some training wheels :)

fishgrrl

I'm looking to use people to integrate into my site as well. I read the link above, and I think I understand what its supposed to do. But its not what I want it to do. Right now, my site doesn't use any login scheme, so I was hoping to use Vanilla's sessions to control the rest of the site. Are there any tips or instructions on how to do that? I tried playing with it a bit to figure it out yesterday but it was a MASSIVE failure. :)

Mark

@moe: No, it's not available to the public. It was a private thing that I did for the client and they wanted to retain the code for their use.

The methodology you are talking about uses an SSO (Single Sign On) server. Basically here is what I wrote for Vanilla:

I created a new addon folder and added the following files:

PostAccountUpdate.php (called by the SSO Server when there was a change to username or password in the other application - so that the changes reflected in Vanilla).
PostLogin.php (called by the SSO Server after it completes it's user authentication - creates a new vanilla session)
PostLogout.php (called by the SSO Server after it completes de-authentication of a user - kills an existing vanilla session)
PreLogout.php (called by Vanilla to log a person out of Vanilla and then send them to the SSO server for deauthentication. This was the flipside of PostLogout.php in case someone clicked to sign out of Vanilla instead of the other app).

There was also a utility.php file which contained some utility functions I wrote for parsing simple xml from the SSO server.

Mark

@fishgrrl: You can totally do that as well. Basically you will need to authenticate the users session on every page load of your application. You don't have to use Vanilla's code to do this, but you need to understand how Vanilla's session management code works in order to write the code for your application.

You can send a user to people.php with a ReturnUrl to somewhere else on your site and it will redirect them accordingly. But to write the integration code for your applications pages, there are two things to consider: (1) Vanilla sessions, and (2) Vanilla cookies.

1) Vanilla Sessions: These are easy. The session contains a single value: the user's UserID from the LUM_User table. If the user has an active session, you can grab any information about the user that you may want to use in a page by querying select whatever from LUM_User where UserID = $TheUsersSessionUserIDValue

The name of the session's UserID parameter is defined in Vanilla's configuration file as SESSION_USER_IDENTIFIER. The default value for this is: LussumoUserID.

2) Vanilla Cookies: The cookies are used to "remember" a user through different Vanilla sessions (if they check the remember me box). If a user comes back to your site after a day away, you are going to want to re-authenticate them if they have valid cookies. In order to do this you will need to review the cookie values and make sure that they still match the saved authentication values from the user's last visit that have been stored in the database. In Vanilla this is done in the library/People/People.Class.Authenticator.php class in the GetIdentity Method. Basically it goes like this:

Retrieve the cookie values. There are two of them, again their names are defined in Vanilla's configuration file with the COOKIE_USER_KEY and COOKIE_VERIFICATION_KEY settings, which by default translate to: lussumocookieone and lussumocookietwo respectively. Yesterday I changed the way the cookies work a little bit after some issues arose from Entripe.

The lussumocookieone value is the user's UserID. The lussumocookietwo value matches to the VerificationKey value in the user table. So, to authenticate the user you need to select UserID from LUM_User where UserID = $theuseridcookievalue and VerificationKey = $theverificationkeyvalue

Once you've done that, if the UserID returns from the select successfully, you can save the LussumoUserID session value as the returned UserID and you're done re-authenticating.

mjpg

I just installed vanilla.0.9.2.6 and I'd like to integrate the login with a custom CMS. Where or what is 'people.php' or '*_people.php' or 'people'? I don't see it in the download ZIP. Thanks in advance.

litbynature

I do not think People is included with v. 0.9.2.6; only in vanilla 1. i have not touched 0.9.2.6 in a while, so I might be mistaken. can anyone confirm?

mjpg

Is it possible to get code from 0.9.3 or 1.0beta without SVN? If the 'init_people.php' file can stand-alone in 0.9.2.6, is there any way I can get it to test? Thanks.

Minisweeper

It's only come with 0.9.3 or later and wont work with anything before cause there's a generally huge codebase change. You could grab the prerelease (search for it) but if you were wanting to work with people i'd suggest using the svn or waiting for the official release (when mark gets a new server, hopefully quite soon) since that will include the latest cookie changes too.

mjpg

Thanks for the information - much appreciated.

moe

@ Mark > There is not really any way for me to know what any given foreign application will require in order to integrate properly. So, the type of integration you are talking > about needs to be a custom solution and doesn't really apply to People. Well, I think I outlined an approach that works for *any* application, no? ;-)

divorcetheworld

Is it possible to configure the cookie to be saved with the username rather than the userid?

Mark

Of course. Just write your own custom authenticator. As long as the methods in the authenticator serve the same purpose (returning the UserID), it doesn't matter what you put in the cookies or session.

divorcetheworld

Alright. Thanks. Unfortunately, I was hoping it would be a little less complicated. I'm very much an amateur. EDIT: Does that mean only revising the People.Class.Authenticator.php? Just wondering what I'm up against.

Mark

Yes, you just create a copy of the original and modify it.

Just make sure that each method continues to serve it's purpose:

Authenticate: validates user input or cookies and creates session and cookie variables.
Authenticator: constructor.
DeAuthenticate: destroys cookie and session values.
GetIdentity: Looks at the session variable and returns the userid based on that.


Why do you want to change the cookie to show usernames, anyway? What difference does it make?