Authentication via another user database

grav, have you already looked into docs/EMBEDDING, and modules/core/classes/GalleryEmbed.class?
also take a look at page linked in my signature (Embedding & Integration).

Basically, you map users of your own application/database to users of G2. (GalleryEmbed::addExternalIdMap() for existing users and GalleryEmbed::createUser() for new users).
Then, instead of accessing G2 via main.php, you create a new file, e.g. gallery.php and you initiate G2 with GalleryEmbed::init(array('activeUserId' => $userIdFromMyDatabase, ...));
and then you generate the G2 page with GalleryEmbed::handleRequest();

I've read the embedding doc, and looks at the GalleryEmbed class, and it's way over my head. I know enough PHP to write a website that integrates with a simple database, but I can't follow what's going on here. I know far more perl.

Pretend for a second that I even know where to override/add the addExternalIdMap call, isn't this going in reverse? I have an app (in perl/mysql) that's been in use for over 5 years, and has an established userbase (of old friends). I'd like to let them use the same username/password in gallery without reregistering.

I can handle the two admin interface to assign privileges, and I don't need them to be able to register via gallery, but I just need one thing (subtopics for clarification):

(1) Have gallery query a different database to ask if this is a valid username/password.
(a) If the username is valid but no gallery username exists, create one.
(b) If the username is valid, and an identical username exists in gallery, use it.
(c) If the username is invalid, reject it and/or treat them as a guest.

I don't need the ability to make it seemlessly integrated (though that's a nice feature, I host other sites that use embedded gallery), I just want a single logon solution using a registration process provided by a separate app. Seems like this could be done in a general way by providing gallery with (a) the credentials for the other database (dbname, host, username, pw), and (b) the name of the fields (username, MD5(password)).

All the embedding docs I've come across seem to want to do far more than that. I don't care if cookies transfer across. I don't care if deleted users take up space in the gallery db. I don't care if it looks like it's all one application.

Can anybody provide hints as to how to do this?

here's how it works:
Your existing site has existing users, G2 has only the default users right now.
- You map the default g2 users (admin, guest) to the corresponding cms users with GalleryEmbed::addExternalIdMap();
This will add an entry in the g2_ExternalIdMap table which tells g2 which cms user id corresponds to which G2 user id.
- foreach existing cms user you call GalleryEmbed::createUser(). this will create a corresponding g2 user with the same user name, and user data and it will automatically add a map entry in the g2_ExternalIdMap.
- foreach user that registers with your cms, call GalleryEmbed::createUser()

The way g2 integrates with your cms is that g2 gets called by your CMS. you don't access g2 directly anymore (you can, but that's an exception).
so the request comes from a user from a web browser to your cms, e.g. with a GET variable ?module=g2.
In your CMS, you check if the GET variable 'module' isset and if it's == 'g2'. If so, you call

include('./gallery2/embed.php');
GalleryEmbed::init(array('activeUserId' => $cmsUid, ...));
$data = GalleryEmbed::handleRequest();
// output data.

the details are in the mini script that i attached to another forum topic. the link to it is in the first post of the Embedding & Integration topic.

in the GalleryEmbed::init call your cms tells G2 which user is logged in. if it's a guest, just set $cmsUid to ''.
g2 will then look up this id in the g2_ExternalIdMap and then it knows which G2 user to load.

each time a user updates his user data / password in your cms, call GalleryEMbed::updateUser() to update the corresponding data in the g2 database.

why so complicated? it isn't that complicated and we explored also the single user db table alternative.