Is there a way to avoid having to create DBman accounts for all my authenticated users? I'm placeing the script in a members only area that is accessed by a username / password. The script assumes the uid to be the authenticated username. I really don't want to create 1500 accounts in dbman. Is there a way around this?

Hi Ashlar,

Explain a little more what you want the access to be, as I think you might not be approaching it right. Consider:

1. Do you want record ownership -- i.e. can a logged in user only view, or only modify a record he created? Or can a logged in user do something to any record?

2. Do you want different permissions for different users? i.e. if you log in as joe, you can add and delete, but if you log in as bob, you can only delete?

3. What's the purpose of the .htaccess file? Is it just so you don't have to add in the users into DBMan as well?

Let me know the answers to those, and I can recommend something..

Cheers,

Alex

 
Yes. And I've set up the script so that a user can add themselves, then add records, and edit only those they created.


Not necessarily. The admin should be the only one who can delete or modify any record, but each user should be able to modify or delete his / her own record.


It's in a members only area of the site.


Here's the dbman set up outside of the members area.. works beautifully

http://www.webvoodoo.com/cgi-bin/dbman/db.cgi?uid=default

* Anyone can view/modify/delete/add records: Just set $auth_no_authentication to 1.

Umm, that's what I don't want. If it's not behind an .htaccess / .htpassword file, anyone can sign up for an account and add themselves to a contact database. No one can change or delete someone else's record. I would like to have _some_ security. I could probably edit the html.pl file so that the modify / delete buttons never show up, but that's just a hack. I'm sure someone here has dealt with this before, but darned if I can find a post relating to it.

Alex asked Ashlar:

> Explain a little more what you want
> the access to be

He means DBman is assuming that if a person logged onto the server via server authentication, it assumes that's who they're logging in as for access to the database. That's a broken methodology and there should be a way to turn this feature off. What he meant by not wanting to create 1500 users is that with DBman's current configuration, he would need to match every account in DBman to a server authenticated account. Yuck!

I e-mailed him a fix but think others would benefit so I'm posting here as well. Basically, commenting out the sections in auth.pl with $server_auth references will fix this issue. Those lines would be:

my ($server_auth) = $ENV{'REMOTE_USER'} | | $ENV{'AUTH_USER'};

and

elsif ($server_auth) { # The user has logged in via server authentication.
return ('ok', $server_auth, &auth_check_permissions($server_auth));
}

A permanent fix for this is to add an option in the default.cfg file to turn this sort of thing on/off. For example:

$server_auth_allow = 0; # 0 is off, 1 os on

I ran into this issue myself when testing DBman in a secure section of my server and found it to be acting annoyingly presumptuous. What if a server admin set up a single user/password for access to the directory DBman is in but wanted to have separate access acounts for DBman under this single user/password authentication?

1) If the server-authenticated user name is the same as an admin's user name, people will be able to add/modify/delete other people's records. Bad. The admin should decide whether people have to login regardless of server authentication.

2) If the server-authenticated user name matches a user in DBman's .pass file, it assumes that's the person logged in. Not good.

3) If the server-authenticated user name doesn't match any user in DBman's .pass file, it assumes that the person doesn't have an account and gives them the default permissions. This also causes the default script URL (db.cgi, no query string) to not show a login screen and all the edit options are not there. This mistakenly makes the person setting up DBman think they need to edit the HTML when all they really need to do is stop DBman from assuming something about the user based on a server-authenticated login.


------------------
--
Jihad Battikha
http://www.highsynth.com/

Thanks, Jihad, that was EXACTLY what I meant, and EXACTLY what I needed.

One more line in auth.pl I forgot to mention:

if ($ENV{'REMOTE_USER'} | | $ENV{'AUTH_USER'}) {
$username = $ENV{'REMOTE_USER'} | | $ENV{'AUTH_USER'};
}

This should be commented out as well to avoid server-authenticated login issues.

------------------
--
Jihad Battikha
http://www.highsynth.com/

Ashlar: Sorry about not getting back to you, I missed your reply. Glad you got it worked out!


No, if it can't match the logged in user with a user in the .pass file it assumes the person does have an account, but does not have any permissions to do anything. (Hence they go to the home page, but are unable to add, remove, delete, view).

The motivation behind server based authentication is let DBMan work with another program or another section of the site. It allows the user to move seamlessly from DBMan to some other application without having to log in twice.

The admin is still burdened with having to sync the .pass file and the .htaccess file together though.

Hope this helps, and I know it could definately use some clearing up in the docs about this un(poorly) documented feature.

Cheers,

Alex

OK, thanks for clarifying that a bit further, Alex. I admit I didn't go deep enough in the code to discern what it would actually do if a server auth. login name didn't match a name in the .pass file. A good defaulting logic.

I still think, however, that server auth. should be an on/off flag in the default.cfg file. It's fairly easy to wrap those sections of auth.pl in an if/then block. This would let the webmaster decide whether to match up their .htpasswd file with their DBman .pass file.

Thanks

------------------
--
Jihad Battikha
http://www.highsynth.com/

[This message has been edited by Jihad (edited February 03, 1999).]