I searched for this information but I couldn’t find it in the forums or anywhere known to Google.
I’m using MODx 0.9.6.3
We’re a public library and our catalog system has a database with an API for verifying usernames(library card numbers)and passwords, as well as getting all the other information (names, email, addresses, etc...).
What system events do I need to hook to so that I can authenticate off this database without checking to see if a user exists in MODx’s own usertable (for either web users or manager users)?
Basically on what event do I run:
$verified = OPACverify($username, $userpassword);
and what do I return?
For Bonus Points:
I can tell whether they’re a child, teen, or adult based on $ptype. How do I add the correct group?
e.g.
select ($ptype) {
case "child":
//is there an easy way to add the group "children" to this user w/o storing them in MODx’s database?
break;
default:
break;
}
Thank you in advance.
Someone else will likely chime in with some more directly useful information, but if you search the site for "imap" there was at one time a add-on to authenticate against a mail server which may provide some hints.
-
MODX Staff
- 10,725 Posts
If this is for the front-end of your site, you can bypass the MODx Web Users system altogether and simply put this code in a snippet on any template that should check this data (or plugin registered to OnWebPageInit if you want it on every page). Just depends on your requirements and how you are going to use this data.
Quote from: cdm014 at Oct 08, 2009, 02:55 PM
I can tell whether they’re a child, teen, or adult based on $ptype. How do I add the correct group?
e.g.
select ($ptype) {
case "child":
//is there an easy way to add the group "children" to this user w/o storing them in MODx's database?
$_SESSION['ptype'] = 'child';
break;
default:
$_SESSION['ptype'] = 'undefined';
break;
}
To childproof a page (if that’s what you want to do), you can put a snippet like this at the top of the page:
if ($_SESSION['ptype'] == 'child') {
$modx->sendRedirect($modx-makeURL(##));
}
Where ## is the ID of the "sorry kid -- you’re not authorized to see this" page.
Thank you for the responses. As I’m sure is usual, answers have prompted more questions.
I was asking about using most of the core system (except the user tables) because I’d like to stick to it as much as possible. (Plus I think it will make it easier if we upgrade to version 1.0)
Also I’d like to use the same authentication for the back end. This is another reason I want to stick to hooking into events. Is it possible, to add/change the roles and groups assigned ’on the fly’?
My real issue is I have no way to simply copy the table of our card holders and their ptypes out of the existing database, I can basically just run queries on it. So somewhat with a front end login, and especially with a manager login, I would like to authenticate the username and password against my database, and then assign groups and roles based on $ptype (if it’s a staff member it will tell us what department they belong to).
OpenGeek will correct me if I’m wrong, but I think a plugin tied to onWebLogin and onManagerLogin won’t quite do what you want. IIRC, a plugin can invalidate and abort the login, but can’t bypass the regular authentication -- I could be wrong.
I think that, in theory, your plugin could use onBeforeManagerLogin and onBefore WebLogin. It could then authenticate via your own DB, then check the MODx user DB and, if the user is not there, add the user/password to the user table and to the appropriate user groups before the standard part of the login occurs.
If that’s the way it has to be, then so be it. However, I’m going to hold out for a little while to see if there’s a better solution.
That looks right to me.