Gossamer Forum
Home : Products : DBMan : Installation :

Config Problems

Quote Reply
Config Problems
I'm having difficulties setting up the default database. With my initial configuration, the basice db.cgi file worked as expected and let me login as admin with password admin. Once in I attempted to execute any of the commands (Add, Search, Delete, Modify, etc.) and received the following page/ error saying that an invalid/expired session.

Database Manager Demo: Login Error

Log On Error

Oops, there was a problem logging into the system: invalid/expired user session.

Please try logging in again, or contact the system administrator.
User ID:
Password:

After that I followed the directions in the db.cgi file to specify the full path to the directory of $db_script_path and received the following error report. I'll include the two files at http://www.waynewood.org/db.txt http://www.waynewood.org/default.txt Here's the error page, any help will be greatly, greatly appreciated.

CGI ERROR
==========================================
Error Message : Error loading required libraries.
Check that they exist, permissions are set correctly and that they compile.
Reason: Can't locate http://www.waynewood.org/cgi-bin/dbman/html.pl in @INC (@INC contains: http://www.waynewood.org/cgi-bin/dbman /usr/libdata/perl/5.00503/mach /usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd /usr/local/lib/perl5/site_perl/5.005 .) at default.cfg line 51.

Script Location : db.cgi
Perl Version : 5.00503
Setup File : default.cfg

Form Variables
-------------------------------------------

Environment Variables
-------------------------------------------
DOCUMENT_ROOT : /um01/3/173/public_html
GATEWAY_INTERFACE : CGI/1.1
HTTP_ACCEPT : image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, */*
HTTP_ACCEPT_ENCODING: gzip, deflate
HTTP_ACCEPT_LANGUAGE: en-us
HTTP_CONNECTION : Keep-Alive
HTTP_HOST : www.waynewood.org
HTTP_USER_AGENT : Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
PATH : /usr/local/bin:/usr/bin:/bin
QUERY_STRING :
REMOTE_ADDR : 64.20.134.234
REMOTE_HOST : nas-134-234.nyc-t.navipath.net
REMOTE_PORT : 2993
REQUEST_METHOD : GET
REQUEST_URI : /cgi-bin/dbman/db.cgi
SCRIPT_FILENAME : /um01/3/173/cgi-bin/dbman/db.cgi
SCRIPT_NAME : /cgi-bin/dbman/db.cgi
SERVER_ADMIN : [no address given]
SERVER_NAME : www.waynewood.org
SERVER_PORT : 80
SERVER_PROTOCOL : HTTP/1.1
SERVER_SOFTWARE : Apache/1.3.6 (Unix)






Quote Reply
Re: Config Problems In reply to
The following line:

Code:
$db_script_path = "http://www.waynewood.org/cgi-bin/dbman";
in your db.cgi file is incorrect.

Either use one of the following configurations:

Code:

$db_script_path = ".";


OR

Code:

$db_script_path = "/absolute/path/to/cgi-bin/dbman";


Change /absolute/path/to/cgi-bin/dbman/ to the ASBOLUTE PATH to your dbman directory, not the relative URL.

Regards,


Eliot Lee
Quote Reply
Re: Config Problems In reply to
It's probably best to put the $db_script_url back to what it was before. In almost 3 years of working with this script, I've only seen two people who I know of that had to enter the path.

Who is your hosting company? There was a problem with folks at 9netave.com and there's a fix for it.

Once you change back the code in db.cgi, here's what I want you to do.

Go to your dbman directory from your FTP program. Open up the auth directory. Delete all files that may be in there except the index.html file.

Log in to DBMan. (Leave your FTP program open. You're going to need it.)

Immediately after you log in to DBMan, go back to the FTP program and look at the auth directory. You may need to reload the directory. There should be a new file in there, with the name that looks like the login name, dot, a very long number -- something like admin.98765432123465. Just look to see if it's there.

If it is, again go back to DBMan and click on a link -- any link.

Once more, go back to your FTP program and reload the auth directory. See if that file is still there (assuming it was there in the first place).

Let me know the results of your test and I'll be better able to pinpoint the problem.


JPD
Quote Reply
Re: Config Problems In reply to
JPDeni, you're amazing. I've read all of your responses and checked out your site (all to no avail unfortunately), but now you've hit the nail on the head on this one. I am using 9netave.com for hosting (do not recommend it), and the password file is getting deleted or timed-out. When I ran the FTP trick you suggested, the file admin9379... was created and then when I clicked on a link it disappeared. What do I do now. Thanks a million for your help.



Quote Reply
Re: Config Problems In reply to
Fortunately, there is an easy fix for this.

Open up the auth.pl file and look for sub auth_cleanup near the end of the file. Find the line


if ((stat("$auth_dir/$file"))[9] + $auth_time < time) {


and replace it with


# 9netave is 8 hours behind current time
if (((stat("$auth_dir/$file"))[9] + $auth_time + 28800) < time) {


This fix is compliments of a user named oldmoney who is also a 9netave customer.


JPD
Quote Reply
Re: Config Problems In reply to
Once again you've got it. Do you have any idea why 9net's clocks would be set back like that (It's not set to Greenwich Mean Time is it?)? Everything works fine, but I do have a second question. I would like to install the script in a sub-sub folder in my cgi-bin. When I had all of the difficulty setting things up I resorted to the default cgi-bin/dbman, but I'd really like to place it in cgi-bin/ww/directory (the ww is a protected directory and the directory folder is simply to keep things clean. When I specify this in the default.cfg file, and call the script, I get a default page with no permissions without any login page.

Database Manager Demo: Main Menu

Main Menu

Permissions:
This database has been set up so any user can view any other users information, but you can only modify and delete your own records. If you have admin access, you can of course do anything you like.

Enjoy! and let me know if you have any comments!

| Home | Log Off |

Below is the default.cfg entry:

(# URL of the directory dbman resides in. No Trailing Slash Please.
$db_dir_url = "http://www.waynewood.org/cgi-bin/ww/directory";)

Once again I appreciate all of your help. I wish you were on the forums for other scripts because I have yet to get a script installed without a glitch.





Quote Reply
Re: Config Problems In reply to
I have no idea why 9netave would set their clocks so strangely. It's the only server so far that I've seen do this. The next time someone has a problem like this, I'll just ask them if they're on 9netave and give them the fix. Much faster. Smile

Regarding your subfolder. I'm not sure what the problem is, but I have two ideas.

One is that the permissions aren't set correctly in your default.cfg file.

The other (and now that I think about it, more likely) problem is the protected directory. Is this protected through .htaccess? If so, I'll have to do some searching to remember what to do.


JPD
Quote Reply
Re: Config Problems In reply to
Yes, the directory is protected with .htaccess. Could I make this any more difficult?

Once again, Thank you, thank you, thank you


Quote Reply
Re: Config Problems In reply to
In Reply To:
Could I make this any more difficult?
Smile Well, there's a workaround for just about everything.

DBMan takes the input from the server authentication and checks to see if there is a corresponding username and password in the .pass file. If there is, the user is logged in with the permissions in the .pass file.

Option 1:
You could add the same set of usernames and passwords to the .pass file as are in your .htaccess file. That way, they will only have to log in once and will have the permissions. The drawback to this is that you will have to add the usernames and passwords to the .pass file (via the "Admin" link in DBMan).

Option 2:
You could eliminate server authentication in DBMan. The drawback to this is that, if you want users to log in to DBMan, they will have to log in twice. You could just have all users except yourself log in as "default" and then they would just use the server authentication to enter the directory and wouldn't have to log in to DBMan.

Option 3:
You could set $auth_no_authentication=1 in the .cfg file. The drawback is that no one -- even you -- would be able to log in to the database. This would be only useful if you were only going to work with the database offline and upload changes to the .db file yourself.

I'll explain how to accomplish your desired option, once I know which one would be best for you.

A lot depends on what you want to do with the database. I guess now my question is, "what do you want to do with the database?" Smile


JPD
Quote Reply
Re: Config Problems In reply to
After a couple weeks of thinking, and being generally busy, I'm back to this dbman config. Let me describe what I need to do. I have a site that is completely member's only access that I currently have restricted by .htaccess. Inside the site I hope to have a database (using dbman) of user's personal information which is probably the most sensitive part of the site. I currently have Account Manager Lite (http://cgi.elitehost.com) setup to manage the user access to the files. User's sign up and upon approval, the script adds their login to the .htpasswd file. I'm wondering if I could use dbman to accomplish the same thing, writing to the .htpasswd file the same way Account Manager Lite does, and eliminating the need to signup twice. I could then put either dbman's signup screen behind a different .htpasswd file so that new user's would have to use a known username and password, or I suppose there could be a question built into the dbman's signup form that could authenticate users. This still brings up the issue where the dbman, or part of it might have to be within the password protected area (the database would be the single most sensitive). What's the security of the file as is. As far as I know no one has access to any files other than html and cgi script's within my cgi-bin (hosting through 9netave), but I don't know if someone couldn't write another cgi script to access it, or any other cgi vulnerabilities that they could exploit. Someone suggested putting

<Limit GET POST PUT>
deny from all
</Limit>

in the .htaccess file of the auth directory and I wonder if that wouldn't be possible for a directory holding all of dbman's info. As a separate, but related question, do you know if it's possible to use an HTML login form like dbman's and/ or pop-up javascript prompts to enter .htpasswd information? Is there a way to disable the checkbox option to cache .htpasswd information that is on the login window in IE5? My undying gratitude to anyone who can answer any or all of these questions.

Quote Reply
Re: Config Problems In reply to
Here's what I did that seems to be working fine.

Create a .htaccess file:

Code:

AuthUserFile /full/path/to/cgi-bin/dbman/default.pass
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic

<Limit GET POST PUT>
require valid-user
</Limit>


The DBMan .pass file seems to work just hunky-dorey as a .htpasswd file, even though there's more stuff on each line than is necessary.

JPD
Quote Reply
Re: Config Problems In reply to
I am having the same problem - I can log in, but when I click on a link I get the "invalid/expired user session" error message. I did what you suggested - checking the auth folder. It creates the file when I log in and then it vanishes when I click on a link.

However, I'm trying to set this up at dellhost.

Any suggestions?

Thanks!
Kristen