|
| Can I use these scripts with the cgi-wrap package ?  | admin |
| | 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. |
|
| My server just can execute perl scripts with extension .cgi (no .pl) what can/must i do? | Wacko |
| | 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
|
|
| What do the access level numbers represent? | madskillz |
| | 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. |
|
| How can i call and display the additional database datas in auth1.5 | digitalkollam |
| | 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.
|
|
| How can I restrict registering with usernames like "username" "Username" "USERNAME" etc in AUTH1.5 | haricnair |
| | 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. |
|
| Authentication System 1.5 is'nt updating the .htusers password file¸ any idea's why? | Lee |
| | 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.
|
|
| Why can't I access images in my /icons/ directory | admin |
| | 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. |
|
| I have installed correctly and auth works ok but dl_edit says no cookie was sent | admin |
| | 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
|
|
| What is the procedure to get the authsys to work on HTML/SHTML pages? | ShermanCahal3 |
| | 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. |
|
