hopefully these will help more than hurt...

(a few random, specific things in no particular order)

• rather than use an outside time program (/bin/date) you can use localtime. This will avoid a shell call which is usually a Good Thing(tm).
• never, never, never set a file to 777 permissions. There are too many ways that a universally writeable file can be abused, just don't do it. 644 is better.
• For your print statements, you can bundle like things by comma-seperating them rather than using individual print statements.
• You should use cgi's methods for getting the arguments passed to the script. Realizing you're already heard use CGI or die many times, i'll give you a reason: You're not restricting content length. A cracker could easily use that to break into the system. Parsing cgi arguments correctly is very difficult, (ab)using CGI is much easier.
• It would probably be better to store the single-user password in the access.txt file. Storing passwords is in general a bad idea, but there's only so much you can do to circumvent that problem when doing cgi work (storing them in the script is not a good option)
• If you can find a way (at a later date) to use a random salt, that would be better than hardcoding one. Much more secure. You can find an example of how to create one on crypt's perldoc page.
• You don't check to see if you actually opened the log file. What if you failed? Currently you continue as if nothing went wrong. Should you die? Warn others? Whether you fail gracefully or gracelessly, you should do something when you fail...
• A very minor nit, but possibly useful. Rather than saying:

  if (($in{'name'})&& etc...

  it seems better (monks correct me if i'm wrong) to use exists here:

  if (exists($in{'name'}) && etc...

• to reiterate a few others, strict and warnings are useful. Also, test your script out on command line before putting it in cgi_bin. That will help clear out a lot of other possible pitfalls early as well...
• Lastly, @_ is your friend. Argument passing is an excellent thing to learn, and using strict will become much easier once you stop using globals.

As for coding, don't try to implement a lot of changes at once (assuming you're still making changes). It's just a bad idea (unless you're a real programmer like mel ;-). Whatever changes you plan to implement, make them 1 at a time. And if you can stomach it, you should probably post the next (major) revision to Seekers of Perl Wisdom if you plan on asking for further advice. You'll probably receive more help there.

jynx

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.