Documentation on writing bridges? (Or, hijacking Coppermine's user system)

[Promit]

Are there any docs on how to write bridges? I'm designing a new website from scratch and I'm trying to decide whether to write my own user management system and bridge it with Coppermine, or whether to piggy back on Coppermine and modify it as needed.

So, a couple questions in a similar vein...

I was poking through the Coppermine code, mostly just cursory glances at how it was interacting with the database. First of all, I don't see anything that would cause problems if I simply added more fields to the users table. So I don't see any reason I couldn't simply write my own systems to also interact with this table, use Coppermine's names, and leave things happily like that.

I noticed that Coppermine stores passwords in plain text in the database, and I'm uncomfortable with this. If I hash the password on registration, and on login, will it break anything? I'm aware that the forgot password script sends the password over email; I can rewrite this to use an activation code to reset the password. Are there any other spots I need to watch out for where the password is used?

If I'm interacting with the same database as Coppermine, is there anything I should be careful about changing? Things that could potentially break the system?

Thanks.

[Joachim Müller]

There are no docs that explain bridge writing, sorry. Things to keep in mind: coppermine's code and db structure will change from version to version. New version releases always come with an upgrade script that will perform the needed upgrades (e.g. one of them being md5 encryption of passwords in the db for cpg1.4.x with a re-worked "forgot-password" scheme as a result). When using the coppermine user db for your own purposes, upgrading will become harder. The way bridges work has been changed significantly from cpg1.3.x to cpg1.4.x (which still is in beta stage though). If you're in the process of writing your auth and user management system from scratch I suggest using a bridge system based on cpg1.4.x, which is much simpler (in terms of "coming up with a new bridge file for another app") than the one from cpg1.3.x.

Joachim

[Promit]

I forgot to thank you for the response. Anyway, how stable is Coppermine 1.4.x right now? I understand that it's in beta and bugs are to be expected, but it won't blow up in my face, right? So that although everything might not work correctly, it's still 'stable'? And all the important things work?

Oh, and...I can't seem to actually find a 1.4.x download. Is it CVS only atm?

[kegobeer]

It's stable, and at this point there shouldn't be any major changes.  (I say shouldn't, but you never know.)  Not for use on a production site, no warranties, etc, etc.

[donnoman]

If one was to want to write more user attributes for other purposes, I would create a table specifically for the extra attributes, and simply reference coppermine's user_id to tie the two together.

That way you insulate coppermine changes and your own tables from each other.

[Promit]

Ok, so I downloaded 1.4.0 from CVS (the devel module) and I've got Coppermine up and running...sort of. I'm trying to just use it as standalone at the moment, and maybe I'm just blind...but I can't see a way to register for a login?

[Promit]

Ok, I am blind. Never mind.

[Promit]

Ok, so I'm poking into the sources for various bridges, and I have some questions... (CPG 1.4.1)

First of all, collect_groups. What is the purpose of this function? Every implementation seems to follow the same pattern. But I see lots of +100s everywhere, like so:
$udb_groups[$row[$this->field['grouptbl_group_id']]+100] = ucfirst(strtolower($row[$this->field['grouptbl_group_name']]));
Why is there a +100 in there? Something to do with post based groups, from what I can figure, but I'm not sure...

Second, udb_hash_db tells the system how to take the password entry in the database, and convert that to the type that's used in the cookie? So, for example, if the cookie stores the sha1 of the password, then this function should return sha1( $Password ); ?

Is it necessary to provide the class with the actual authentication info in the constructor? Or can we auth with our own database code and somehow give it the database resource?

What, exactly, is get_groups for?

I'm unclear on exactly session_extraction and cookie_extraction are supposed to be doing.

[Nibbler]

Writing docs for the new bridge system is something I aim to get around to doing soon, but I'll answer these questions now.

collect_groups is to grab the custom groups from the forum where the forum has some special requirement or query to get the groups list, eg phpbb has an extra condition in the sql, for some forums we can just read them straight from some already provided user data array. The +100 is so that the groups from coppermine and groups from the forum do not conflict. Coppermine groups would be eg 1,2,3,4 and the additional forum groups would start at around 100. (some group ids can be negative). As a sidenote, the term post-based-groups is a little misleading, this actually refers to using the true groups defined in the forum, not specifically post based ranks.

udb_hash_db can be used where is some seed unique to the installation that needs to be combined with the database password to form the cookie password. punbb in particular uses this. If both the db and cookie hold the same type of hash then you don't need to use this.

Yes, you can provide an existing db connection id to connect() at the end of the constructor. SMF is a good example of where we do this.

get_groups is used to get an array of all groups that the user is in for forums that support multiple groups. Multiple group membership is implemented in different ways in different forums.

session_extraction and cookie_extraction are 2 different ways to get auth info from the user. Many forums use 3 cookies, 1 with a session id, 1 with the user id and 1 with a password hash. Some use full blown sessions, so that can be used too. It should return the id and password hash the browser is providing. Having 2 methods makes things more reliable, the IPB2 bridge is a good example here. The session method takes priority.

You can of course skip those 2 functions and do all the authentication yourself by overriding the authenticate method. The phorum bridge does this, we include its authentication file and trust the information that comes back.

[Promit]

Hmm, I'm still pretty vague on how the groups work.

What I want to do is set things up that Coppermine and my system have the exact same groups, but the permissions relevant to Coppermine are in the cpg140_usergroups and the permissions relevant to my system are in my own table. Joining these two tables would yield a complete set of permissions. How exactly would I write that in the bridge?

[Promit]

*bump* I'd really appreciate an answer on the last quesstion 

[Nibbler]

I don't see why you want/need to. The only permissions that are relevent are those in the coppermine usergroups table.