I found this perl script this morning, that does what I would like to do. However, I want to take it about 2 steps further and integrate what it does with DBMan. Anyone up to helping me with a challenge?

The script is from Ranson's Scripts. It's a free script that is called password+redirect. You can get it at:

http://rlaj.com/...ssword/passwd-redir/

What it does is maintain a password file that when you login directs you to a specific url.

VOILA! Step 1 of what I need, a generic form on our corporate site for clients that lets them log in and go to their client files without knowing the behind the scenes way to get there (we don't want/won't have a links page for all clients)

So, this takes the Client A to Client A's Index page for their DBMan database access and other specific files (reports, etc). But it takes Client B to a different page specifically for client B.

And another thing it does, is block the user from linking to underlying pages. They can ONLY link (send to desktop or make a favorite) the login page. Which is cool, because I can change the links on the back end however, always leaving the login page the same and the client will never have bad links and never really know where they are going on our site.

I would like to be able to integrate the DBMan .pass files SO that a user who is set up with a login and password can login once and skip the DBMan login page going straight to their assigned default.db

The challenge in doing this is that I can't have one big .pass file for all clients. I have 2 levels of admin set up, one is a client admin level and they can assign users and passwords. Then I have a superadmin, which is a Corporate level admin and we can do anything.

Since I've allowed Clients to set up their own users, there is one .pass file per client. Each client .pass file has one login/password combo that is for superadmin and they can't see/change that.

Now, taking that and applying it to the new script which is a login for all clients from one form, what would be ideal, is to be able to require all the other .pass files and have the login be maintained at the client level but usable at the corporate level --

So if Sally at Client A wants to login. She goes to the login page. puts sally/sally in for her login/password and is redirected not only to Client A's index page, but also is already logged in to DBMAN (her uid is passed from the initial login.

I can see a few issues.

1 - Can the password file use an require to include all the other password files?

2 - I may need another field for the Client name so that I don't have to worry about uniqueness of login name (among all clients - they still need to be unique at that client site)

3 - passing the uid from the first login and getting to the right page for the client with DBMan understanding what the heck is going on! (maybe if the first login is generated by a Master DBMan default.cfg?)

4 - I want there to be a default form for "you are not a user yet" when the login fails and send an automatic email to the admin and superadmins for that client/or just to superadmin if the client has no database yet!

5 - eventually moving all this to DBMan sql because we are quickly multiplying the use of this and flat files aren't going to be able to handle it much longer. Plus with SQL I only need multiple tables per client and can keep everything in one master database.

Ideas, suggestions, thoughts? I hope this is clear enough!

Thanks for any advice, horror stories, or suggestions you can give me. Even if it is to say "you are totally crazy!"

Lynette

I have several comments, where to start?


When I look at the DBman demo login sucess, funny I can't see the username and password in the URL, I wonder how they do that? Really, how did they hide the URL that was posted? I would look into that first.


Hum? that works for the first page following login, but not for each and every page after that. Couldn't they still bookmark pages following a dbman search or modify_sucess? Unless you plan to use the same method as the other script for all your "search results".


That does not sound too hard, since a dbman login is just a long link with user name, password and the other "key element" such as;

http://www.herbicide-adjuvants.com/...author&pw=author

Regarding users created by the client and avoiding duplicate user ID's across clients; not too hard to append the client name to the front (yea, append to the front, that's SOOO wrong) of the client created user name without them knowing it. Not too hard? let's see, client creates new user, something needs to automatically ALSO create the user in the MASTER database with client name added to the front , then when user logs on, user name is modified (based on client, HOW? 3 fields to logon?) and is passed on to the MASTER database ???? OK maybe it will take some thought.

To quote myself and then I seem to be able to answer my own question;


I find that whenever my form includes the following, the URL is hidden.

<input type="PASSWORD" name="pw">

Note that I need not read it, as long as it gets posted.

Must be a Browser rule??? Can anyone confirm this?

Still learning.

Perhaps this thread will help to answer your question:

Thread: http://gossamer-threads.com/p/000696
Topic: Need feedback in attempt to use a Links/Template Generated webpage access DBMan.cgi
timryan - posted August 12, 1999

The portion of the thread that may be the answer to your question on how DBMan functions with the login by JPDeni.

===
Yes, the $db_userid changes with every login. It's the username of the currently logged-in user.

Here's the "birth and life" of $db_userid in a nutshell:

A user logs in with his username and password.
The script goes to auth.pl, sub auth_check_password.
In this subroutine, the username and password are compared to entries in the password file. Then a random number is appended onto the username, with a . in front of it. For example, if I were to log in as "fred," the result might be "fred.9876543456789". This becomes the $db_uid that is in each of the forms. A file is created in the auth directory with a name that corresponds to the uid.

Then the script moves down to sub auth_check_permissions, which again looks at the password file to see what this user is allowed to do.

Now the script goes back to db.cgi, carrying with it the whether or not the login went through ok, the $db_uid and the permissions.

The $db_userid is derived from the $db_uid by chopping off everything from the . on. So that "fred.9876543456789" again becomes "fred".

So fred is now logged on to the database and he wants to do something. Every link in the footer includes his $db_uid. It may not be obvious that it does, though. The links use a variable $db_script_link_url, which consists of

-- the url to db.cgi
-- the name of the database
-- the $db_uid

Let's say that fred wants to add a record. He clicks the add record link. The first thing the script does is check him out to make sure he's okay. Again, it goes to auth.pl, sub auth_check_password. But this time he isn't logging in, so instead it looks at the auth directory to see if there's a file in there that starts with "fred." If there is, the script knows he's already logged in, so it goes to check his permissions again. And then reverts back to the db.cgi script.

Whew! The way I learned about DBMan was doing pretty much what I did above. I call it "playing computer" -- I follow the steps that the computer goes through for each command.

========

Hope that was related to what you were asking :)

Unoffical DBMan FAQ
http://redundantcartridge.com/dbman/

In thinking this through, I want a "master" password file built "on the fly" to include all client password files, and login the user based on three fields -- the correct client(district) ,the assigned user id (login name) and the password. Just going through steps here but:

1 - Master password file would include "generic" login for clients (one that has only "guest" privileges) and include statements for all individual client .pass files. (can you use wildcards in an include?) This means all password files have to maintain the same format all the time.

OR -- could I have the first login (the one with the district name, just be used to go to that clients default.db and look at their password file from there for the user name and password/permissions/email?

2 - files I need to modify are auth.pl, html.pl (since I have multiple html.pl's I need to modify the default one that is initially used and probably all underlying ones) and db.cgi.

3 -I need to make sure that every time a user logs in that they are checked out in the password file, that their permissions are attached, and that the database they need is set and that the $db_uid is carried along with them as they use DBMan. (Is there a limit to the length of this string???)

I'm thinking that the "add permission" mod, which I have used several times, is the closest to having all the areas in these files that I need to modify. I'm just thinking that following the logic of that mod, I should be able to work my way through the extensive modes I need to make to do this. In a way, I'm adding a SUPER default permission -- one that then directs them to their specific client database. (If you are Client A, go here, if Client B, go there, Client C, etc)

Does this make sense Lois? Do you see any big holes? Something major I'm not covering in my planning/thought process? This seems complicated but not impossible as long as I move through it in baby steps.

Nothing like a sunny Monday morning to start a new project!

Thanks for the guidance.
Lynette
Hollister, Ca