pmas

To make errors is human. But to make million errors per second, you need a computer.

Frankly, it's easier just to learn about how to put together a simple database than to deal with all the issues that arise from working from flat files. (By easier, I mean maybe not to get the thing running at first depending on your level of familiarity with databases, but over the life of the project, in terms of maintenance and upgrades etc., the time savings will be considerable.)

I'll reiterate what the earlier poster said for emphasis: Only good things will come of learning SQL and some basic database skills. You'll use them over and over (and over and over ...) again in your career. Furthermore, with the advent of high-quality open source databases (I have used MySQL quite extensively for things that don't require the big iron approach of Oracle and am very impressed), your learning curve is not very steep, the learning environment is free and very easy to install (based on my experience with Linux), and the production environment is super-cheap (assuming you're a good citizen and donate a few hundred bucks to the open source group :-).

Hope this helps!

I agree here... I co-manage something like 10,000 users with DB_File. It's a nightmare. I've been working on the SQL version for the past few months, and now that I have the basics working I can safely and clearly say that managing users with flat files is just plain stupid ( if you have a choice between flat files and a relational database )

If you have some spare time, definitely go with mySQL or Postgres.... they rock

2) Using .htaccess and .htpassword is not necessary if you're doing the whole thing with CGI, but why not let the web server do the authentication work for you? OK, so it's not the most flexible or secure method in the world, but it's a start. If you're going to get into using cookies, be sure to read this. Understanding the HTTP headers involved in either method is a good idea.

Also, if you are doing the whole thing in CGI, and you have appropriate access to the server, take a look at mod_perl -- with this you can get at the authentication and access control phases of the web server process directly, as well as getting better performance for your CGI scripts (content handlers).

3) As has already been said, nothing is stopping you except performance. Databases and simple SQL aren't very hard to learn, and MySQL or PostgreSQL cost nothing -- not a bad investment even if you aren't sure you want to use them.

The reason I don't want to use .htaccess, and .htpassword, is because I don't want to have the permissions set to 0666. I need to just sit down and read a chapter on CGI security, or something of the like.

As for #3, the reason is scalability - you want to use a database once your performance degrades. Using a piped text file is good for, generally, under 1000 records in under 10 tables. Get beyond that and you really want to go to a relational database. It's worth the time and effort to learn how to use them, as you'll find yourself using them over and over in your programming career.

In addition, a RDBMS will help with your security questions, too. :)

Thanks.

For the redirection, I was hoping that there would be some sort of operator that would redirect the user, instead of having to load a blank html page which would redirect the user.

Think about it this way - the browser has to get something to know to do something. That something has to be HTML, JAVA, or something similar. Generally, what people do is create a page containing "You are being redirected to XYZ URL. This should take place in 5 seconds." That way, they know they're being redirected.

Anything else beyond that, like what happens at Yahoo or whatever, needs to be done at the HTTP server level, which is out of my league.

Set the "Location" header in the HTTP headers:

Location: http//www.redirect-targetsite.com/;