Gossamer Forum
Home : Products : Gossamer Links : Discussions :

Admin Security

Quote Reply
Admin Security
The admin interface keeps telling me that I need to set a username and password. Supposedly this will set the .htaccess file. What happens is that it appears to accept the username and password, but when I switch pages or close the browser and come back later it just lets me in to do whatever. Obviously this is a fairly serious security concern. Any ideas?

Thanks,
Charles
Quote Reply
Re: [bobl] Admin Security In reply to
Hi,

You should send a quick email to your ISP asking them to allow .htaccess files in your cgi-bin directory. Once they do this, you should see a password prompt, and the warning will go away.

Hope this helps,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] Admin Security In reply to
Well I am not sure exactly what is happening, but the .htaccess file exists, and the Admin interface says that the next screen will prompt for the password, but it never does.

Any more ideas?

Thanks,
Charles
Quote Reply
Re: [bobl] Admin Security In reply to
Hi,

Yes, Apache is currently configured to ignore .htaccess files. You need to send a quick message to your ISP to get them to enable .htaccess files.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] Admin Security In reply to
I just wanted to put the finishing touches on the resolution for this incident in the event that other customers experience the same problem.

As previously noted, the admin script was reporting that the .htaccess file had been updated for password protection when in fact it had not. Or should I say that it was updating exactly as it should, but was protecting the wrong directory. Confused ---let me explain.

Alex suggested contacting the Host and having the .htaccess enabled for the CGI_BIN directory. The problem is that most support folks are going to try and tell you that it is enabled and that the script is malfunctioning. To me it was obvious that this is a very professional script and enabling .htaccess on Apache is pretty much a no-brianer so I really couldn't buy in to the fact that the script was having a problem even though 3 high level techs at one of the largest Hosting companies in the world made that conclusion after trying to get it working for 18 hours.

Fortunately for me I have root access to my server so I was able to determine exactly where the problem was and make the necessary modifications.

To start, you will know if this is going to be an issue for you if you are running on a UNIX box configured with Apache and your CGI-BIN directory is located above your web directory --- that is --- it is not accessable from your website (except maybe through an FTP program, Telnet, or SSH) and is the only directory that you can execute CGI scripts from. When you install scripts to this CGI-BIN it is then executed in the visitors browser by simply typing an address such as http://www.yourdomain.com/cgi-bin/admin/admin.cgi. What is actually occuring is that your CGI-BIN is being aliased in the Apache configuration files with a command such as "ScriptAlias /cgi-bin/ /usr/local/www/yourdomain.com/cgi-bin/." This command is most commonly located in the httpd.conf file, but may also reside in the defaults.conf or any other configuration file that is being called by the httpd.conf file.

OK --- at this point you have a few choices, but obviously a .htaccess file is not going to work since it is protecting the CGI-BIN directory above www, not the CGI-BIN one being executed via the browser below the www level.

What I decided was that I would enable CGI scripts to be executed from anywhere within my website, but still maintain Alias Scripting to use for less secure scripts. Any script, such as Links SQL, that utilizes .htaccess to protect the admin files is pretty darn secure and I don't have a problem whatsoever placing it in a CGI-BIN directory under my www directory.

To allow CGI scripts to be executed from any directory of your website you need to find the command "AddHandler cgi-script .cgi" which is typically in the defaults.conf file or, once again, may reside in the httpd.conf or other specified Apache configuration files. If you have not been able to execute CGI scripts from any directory then this line has obviously been commented out since it is always present in the standard Apache set up files. Uncomment the line, restart Apache and re-install Links SQL in the directory of your choice. Just make certain that it is not an aliased directory.

I obviously know that most of you do not have root access to your server and will not be able to perform these steps, but when your Host is sitting there scratching their "you-know-whats" for three days, while swearing that Links SQL is to blame, you can print this post out and read it back to them. They should be able to correct this problem within two or three minutes.

If this helps just one person from going through what I did then it is all worth it.

Sincerely,
CharlesSmile
Quote Reply
Re: [bobl] Admin Security In reply to
Hi,

I'm almost positive the .htaccess file gets written correctly regardless of where your cgi-bin directory is. As long as admin_root_path is set properly, then it should work.

More then likely what happens is because under default Apache, under cgi-bin you have:

AllowOverride None

in your httpd.conf file, the .htaccess file is ignored. Most ISP's change this so that people can use .htaccess in the cgi-bin directory, but a few don't. Under these circumstances, Links SQL will create the proper .htaccess file, but it won't have any affect.

I'm pretty sure that this is what was happening, but glad to see you got it sorted out.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] Admin Security In reply to
I just had to post. I searched the posts, found the answer and tried to get my ISP to understand it but it took a fight. Alex's answer below is so true! Thank you, Alex! Though the post is old the issue still remains with Apache.

We had the problem of setting the password in the Admin panel (it wouldn't take) before when we installed Links SQL for our first domain. The issue was resolved but not without a lot of hair pulling on some nice person's part. Here we are a year and a half later, we've purchased another Links SQL license, installed on a virtual domain and I don't remember how that person helped us get the issue resolved the first time. I had to get a little "assertive" so that the tech at my ISP would listen (luckily I remembered the name of the conf file). When he pulled the "It's the faulty script - not our problem" routine - I led him to our first domain and showed him the Admin folder and told him it works perfectly. Then I did the same for the other domain -same script, same directory, no go on the password protection. He finally helped me change the appropriate file and immediately the problem was solved.

So folks, if you have this problem - don't give up! Call back and tell them you want a supervisor to get the issue resolved. It's not a faulty script!

Nadine

Hi,

I'm almost positive the .htaccess file gets written correctly regardless of where your cgi-bin directory is. As long as admin_root_path is set properly, then it should work.

More then likely what happens is because under default Apache, under cgi-bin you have:

AllowOverride None

in your httpd.conf file, the .htaccess file is ignored. Most ISP's change this so that people can use .htaccess in the cgi-bin directory, but a few don't. Under these circumstances, Links SQL will create the proper .htaccess file, but it won't have any affect.

I'm pretty sure that this is what was happening, but glad to see you got it sorted out.

Cheers,

Alex[/reply]