You can pass session ID data via the URL. Ugly as it is, that's a viable option (that I see used a lot actually.. kinda drives me nuts but I understand it) for when you don't have people logging in and/or can't guarentee that cookies will be available.
As was mentioned a few times, CAPTCHA methods can help prevent bots and such from abusing your forms. There's more types than just the characters-as-an-image style. I don't know if they call fall under the name CAPTCHA, but there's audible tests, logic tests, math tests, etc. Some are obscure enough to prevent blind bots from using them, but aren't good enough if someone bothers to look at them.
Say you had something that says "Please enter the answer: 5 + 3 = [input box]" or even something like "Type the word [somerandomword]: [inputbox]". That would probably keep out a lot of the bots people just let run wild online, but if any of the bot programmers bothered to look at your page, it'd be simple to re-write the bot to answer the question.
I've seen "password" systems that didn't have you enter a password, but rather click on a sequence of images. Your "password" may be star-wavy lines-dog. You could do something similar when a user filled out a form.
And yeah, never too late to start using mysql_real_escape_string() hah. Well, guess it COULD be too late in some cases, but it's definitely good practice to get into. It'll escape more than just the stuff addslashes() does. Things that are specific to MySQL and secure inserting/updating.
I wrote a wrapper function that does mysql_real_escape_string() but also takes a parameter for the type of data going into the database and returns a 'cleaned' version of the string for inserting/updating. We store phone numbers and SSNs as all numbers, so one thing it does is check length and remove anything that's not a number. Keeps the data consistant and clean too.
But that's another (related) topic.
-TG
= = = Original message = = =
TG,
Great point on the mysql_real_escape_string(). I think I should
actually start using that (better late than never, I guess).
Again, though.... session variables are great, but what about the
overall case? If you're doing a login form and permissions-based area of a
website, sessions are fine, because the user will just have to deal with the
fact that cookies are required.... but what about something simpler? If
we're just posting, say, a contact form, we should require the user to alter
their browser security settings just to send us an email.
--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
