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
