Error 500 is reported as a server error.

When trying scripts this is usually because the script has failed to run normally because of an error in the configuration file. Check your configuration files and if possible the server log files. These should point you in the right direction.

The password to unprotect the excel spreadsheets is marathon


However there is the odd one with a password of kitkat


The spreadsheets may be used or copied freely the password is to protect the sheets from accidental damage by users not to keep people from changing or seeing the formulas and code.

The basic scripts for registering¸ retrieving and editing user details are simply accessed via links to the relevant cgi-script¸ which is no great problem.



SHTML

Server parsed web pages can be customised by using the auth_read.pl script included within the shtml web page. E.g.



< !--#exec cgi="/cgi-bin/auth1.2/auth_read.pl"-- >


This will add the name of the user who accesses the page or it will prompt for registration if unregistered. This provides a simple way to personalise the pages.



Secure Pages



The authentication system also includes a script called auth_secure¸ which will only display the contents of a web page if the user has sufficient access to read the page. The page that is to be secured should be placed in a location that is outside the normal apache html scope to prevent unauthorised access. You could simply use the cgi-bin as the simplest option although it would be better to create a sub directory. The auth_secure is then called as a link from a normal page with the details of the secure page in the link. You must use the absolute path to the file not the apache server path.



/cgi-bin/auth1.2/auth_secure_page.pl?securepage=/var/www/securepages/name.of.secure.page



Note that the secure page does not need to have a .html extension



CGI Scripts



The authentication system was primarily written to secure CGI scripts such as the download manager and news system. It can easily be included in your scripts. How to do this is beyond the scope of this document¸ however there are plenty of samples to crib the secure method from the included scripts.

This is a problem that appears on certain installations. I have not located the cause of the problem but I am investigating.


The problem is that the cookie has the path of the auth installation included in it. This means that the cookie is sent to the www.yourserver.com/cgi-bin/auth1.2 directory but not the www.yourserver.com/cgi-bin/dl1.4 directory.



Workaround



If you experience this problem then you can either :-

a. Install the dlman files in the auth directory. The two will work together no problem.

b. Install the dl1.4 directory in the auth1.2 directory and access as www.yourserver.com/cgi-bin/auth1.2/dl1.4/scriptname.pl

In early releases prior to dlman1.4 the default location to use for the icon images was the apache /icons/ directory. Unfortunately for those people who did not have access to the apache /icons/ directory they tended to create and use a directory called /icons/ in their site. If you do create one and try to access it invariably apache goes to it's own /icons/. Later packages use /images/ which makes life easier. If you have difficulties with using /icons/ rename it to /images/ or similar.

Yes¸ any script that can access the csv database can create a listing. There are several samples in the dlman package that give outputs that are single / dual column and sorted alphabetically.

The simple answer is no. I have not done as much development work in word as excel and so there is none available. As always I like to keep my ears open for a new project so you should e-mail me directly with your requirements but I make no promises.

First you need to make sure that the .htusers file and path is correct in the configuration file.
Next you need to make sure that the .htusers file is writable by the web server. This depends on your server but it is possible that the server runs as a different user to the one who uploads files (ie you) This may require group or even other write permissions.

I make small modifications to the spreadsheets and scripts here for free.
Ideas or requests such as this should be e-mailed to me directly at john@jbayley.com and we can discuss it.

Unfortunately there is no procedure available in auth1.5 to prohibit usernames of any type. The only workaround would be to register these usernames manually yourself this will prevent this type of thing.

Auth1.6 is currently under development and I will look at adding this as a new feature for this version.

To enable the supplementary data, do the following:

edit the language file that you are using in the following way.

1. Find the line (line 75 I think) that says :-

$suppdata_enable = "";

and change it to say the following

$suppdata_enable = "true";

2. Edit the $suppdata[?] entries below this to reflect the titles that you want displayed. for example.

$suppdata[1] = "Select your favorite number";


If you want the field to be a required field then add an asterisk to the end of the description.

if you want the entry to be a list then edit the corresponding $supplist[?] entry


There are some examples in the language file for you to see for yourself.

The access level numbers are designed to represent different levels of access. Level 1 is the lowest and level 9 is the highest. By editing the configuration of the scripts you can assign different levels that are required to run a script. For example level 4 is required to upload a file and although the user can see other entries he cannot edit them without level 9.
The levels are configurable for the different scripts so for example level 4 may be able to upload files in the download section but level 5 may be required to ad dnews entries.

You need to change the default download lister to be dl_catlist.pl or run dl_catlist.pl manually or link in some other way.
To change the default lister run dl_setup.pl and change the entry that says
The name of the listing script there are several possibilities choose your favorite
The options are listed.

The scripts that are named .pl should be renamed to .cgi to enable them to run on your server. Then, edit the configuration file to change the script names to be .cgi

Yes, you can use all scripts with the cgi-wrap ssecurity package. There are known problems with the cookies though. If you or your isp use cgi wrap and your authentication is failing, check the URL that is stored in the cookie and change the $cookiedomain setting in auth1.2 to match the path of cgiwrap.