.
ContactForm, How to Clean up text submitted?
Will write me a ContactForm.
The form part is no problem, and what to do with submitted message.
I will save message to a plain text file: 'contactmsg.txt'

It is the part in between I am not sure how to do.
The stripping of unwanted characters and code.
I just want to allow plain text.

Any hints or examples for me?

halojoy

This can become tricky, and is very important as it can be a security issue. well in a text file not so bad, but if it's going in a DB you definatly want to do an addslashes() to the data and get rid of some other evil characters like the one on the ~ key if you press it without shift. This board blocks it off completely. Well really it should escape it and still display, but it was a quick fix to avoid an vulnubility someone pointed out and I never got around to making it better.

addslashes() - yes I have seen that used frequently in form processing

I will just save (append) to a plain file messages.txt
not to a Database

I will do a search for examples on net, with Google
there are plenty 'simple php contact form' versions out there
mostly with send mail function, but also some for flat text file storage

I find it stupid to send mail, when I have my personal webserver apache
in my own computer, here in my own room

why send Contact form message across atlantic to hotmail.com or whereever
much easier I just open this text file: messages.txt
with my NEdit (notepad in Linux)

Why settle for an 50MB Mail account Inbox?
When I have 50GB ( 50.000MB ) of my own !!!!

This model was used in a flat file guestbook I downloaded.

Is this okay, or do I need to add anything to this model?

I managed to rewrite that guestbook script into a ContactMe script.
Saves submitted contact messages in a plain textfile.
index.php checks out IP-number.
If it is my (127.0.0.1 in this case) redirects to showmsg.php, so I can read all contact messages.
If is other IP-number, redirects to contact-form.php, so they can contact me.

Here is shot of both pages:

Looks ok to me. If you want to really play safe you can do stripslashes() and replace quotes and slashes with their html name. ex: " etc... A problem in php is the magic quotes setting, on some servers it's on on some it's off. When it's on, it automaticly does an addslashes() to $_POST data, but when it's off, it does not. so that can really screw things up. It's probably the hardest thing to deal with when treating user submitted data. So the way I go about it is do a stripslashes() so you make sure it's not \" \\ etc then you can replace the quotes with their html values as they'll apear ok when displayed, and if you ever switch to mysql you'll be safe from the most common sql injections.

Yes, that seems like the way to do it.
My private apache server has magic quotes on.
But if I want to share this script and be sure it work alright, it should have stripslashes.
This script I have rewritten, first thing does stripslashes.

1. stripslashes();
2. htmlspecialchars();
3a. str_replace("\r\n","<br>",$str); 3b. str_replace("\n","<br>",$str); 3c. str_replace("\r","<br>",$str);
One nice feature with this script is, using a SESSION variable to avoid submitting same stuff twice.
This is not unusually to happen. Every time you refresh, you submit a new post.
It also adds latest contact post on top.

halojoy

.
Did some magic quotes, stripslashes, addslashes research.
This first code was found in includes/common.php of an application.
Will always be run in very beginning of most any page.

This other very similiar code and info was found in a forum topic discussing magic_quotes_gpc

Bottomline:
This magic quotes thing is dependent of php/server setting.
Is also so important, that most any submitted data
should be fixed to have correct format. With or without slashes.
Such a function could be run in a general include common script,
before any data from GET POST COOKIE is processed and used.
halojoy

If you are viewing a plain text file (served to you with the http text/plain type) and its just stored on disk, you don't really need to escape anything since it won't be re-displaed. If you are using it in a guest book way then that is different.

It all depends on application.

Yes,
That is of course true.
Sometimes it is not necessary and we can keep it very simple.

But we want to write code, that would work generally.
So called good practice.

Suppose I write this contact form, first as a single module. Working alone.
does not need any stripslashes or addslashes operation of data.
Later I need a contact form for another application, that displays data differently.
I want to use it, istead of write a new contact form for each and every application.

It is good to learn to write php scripts with code that is generally working, in most any situation,
and run on most any system. Linux, Mac or windows.
And using a format for data submitted, that would work well with most any database.
At least we should try to use only one data format for each application , with or without slashes.
Data should be consistent.

When we erite our own scripts, submitting our own data, we have total control.
However is situations, where data comes from an outside source.
One such case is when someone other using some other system is submitting data using forms.
It is good practice to take some meassures to fix data, before storing or displaying it.
This can also be essential for keeping a good safety.
Red Squirrel mentioned SQL Injection.
I do not know what that is, but I know it is no good.

halojoy

Yes this is all true. However efficency is also a good thing to keep in mind. Anyway, if addslashes() + htmlenteties() + strip_tags() + new line processing isn't enough, you could allways go through the file character by charcter and replace everything that isn't a-z 0-9 with an HTML entity, of course that would be horribly wasteful in terms of file size.

You really shouldn't rely on magic quotes being there and bindly callign stripslashes(). Yes its on for your private server but settings change and you'll be suprised at how many problems magic quotes causes. I know you have some detecting code there, but I still say its a bad idea to change the magic quotes setting from a script. Why? Debugging. Between the programmer and server admin at lot of digging has to be done to figure out what te value of magic quote is at any given part of the script. Using seperate functions, say, quote_incoming() or strip_incoming() could be created that will check for the value of magic quotes at run time and either skip or perform stripping or escaping depending. Doing this and avoiding using the $_* variables directly seems to be the most clear way of managing these issues.

Okay,
I will do that.
Thanks.

Very good article on magic quote problem
Magic Quotes and Add Slashes in PHP
Made me turn
magic_quotes_gpc = Off
in my php.ini -> This is also default recommended setting of php.net

With htmlentities() function you have some optional parameters.
So you can decide how to deal with single and double quotes.
From php manual:

I think I finally have understood how to deal with GET POST COOKIE inputs.
And I have changed my contactform script according to this. Works perfectly!
Last thing I had to add, is to first of all make $string = trim ( $_POST[ 'input'] );
This will remove any leading and trailing spaces or linefeeds of input.
(There are also PHP trim functions for removing only leading or only trailing)

Thanks for all thoughts and advices.
/halojoy