[PHP/HTML/SQL] Coding isn't working with php echo?

[chadderbox]

My coding isn't working on php echo!

I have a database in my MySQL and I have it all working, so I edit it and put html code in it to test if it can support html (underlining and bolding as you can see) but it doesn't show up! It's just PLAIN TEXTT, no coding is happening!

HELPP!!!

IMAGE:

[MentaL]

[SerenityFlight]

Post removed for personal reasons .

[chadderbox]

I'm trying to make a page (like home.php or something thats gonna be iframed) that is updatable through a cPanel thingy, which is ran by MySQL... and I think its possible?

[SerenityFlight]

Post removed for personal reasons .

[lordvladek]

its possible, set the row to blob or varchar, use htmlspecialchars. OR write your own system using str_replace. use specific things like [ul][b] use str_replace to set those to <ul> <b>

[chadderbox]

its possible, set the row to blob or varchar, use htmlspecialchars. OR write your own system using str_replace. use specific things like [ul][b] use str_replace to set those to <ul> <b>

The row is at varchar and im using htmlspecialchars but its still not doing HTML code??
Hmm I don't exactly know how to do my own system?

[lordvladek]

//this will be fetched from your mysql table

$var = "[ul]this is a test[/ul]";
$var = str_replace('[ul]', '<ul>', $var);
$var = str_replace('[/ul]', '</ul>', $var); 

Replaces the simple [ul] and [/ul] with their html corresponding chars.
I'd have to see the script to tell you whats wrong though.

[chadderbox]

//this will be fetched from your mysql table

$var = "[ul]this is a test[/ul]";
$var = str_replace('[ul]', '<ul>', $var);
$var = str_replace('[/ul]', '</ul>, $var); 

Replaces the simple [ul] and [/ul] with their html corresponding chars.
I'd have to see the script to tell you whats wrong though.

Parse error: syntax error, unexpected '<' in /directory/page.php on line 12

[lordvladek]

Ah, I forgot a simple ', but in any case I fixed it.

[jMerliN]

Did you read what htmlspecialchars does?

There's no point in doing this for storage. If you want what comes out to be HTML, htmlspecialchars takes special characters (to HTML) and converts them to escaped sequences so they display as plaintext. That is entirely the point of the function.

You don't need to do any conversion really. But a meta language would be preferable. It's generally a bad idea to allow an author to save raw HTML to a field that will be rendered later, it's a huge security hole.

What you should do, more specifically, if you want HTML to be permitted, is to permit only a subset of HTML. I have a bulletin board created for internal use only that does this because I didn't care to make some kind of BB code and because the WYSIWYG editor I used created HTML output by default and I didn't want to tweak that.

I used the function strip_tags which is nice and simple. That's a lie really because what I used mimicked the way strip_tags works by parsing the data and also stripping unwanted attributes from tags (unweildy style attributes, javascript things, etc). But this is a simple way to quickly implement that functionality.

Alternatively, with what you've got, simply calling html_entity_decode on the values you get back from your MySQL queries should give you the HTML you want.

[lordvladek]

Did you read what htmlspecialchars does?

There's no point in doing this for storage. If you want what comes out to be HTML, htmlspecialchars takes special characters (to HTML) and converts them to escaped sequences so they display as plaintext. That is entirely the point of the function.

You don't need to do any conversion really. But a meta language would be preferable. It's generally a bad idea to allow an author to save raw HTML to a field that will be rendered later, it's a huge security hole.

What you should do, more specifically, if you want HTML to be permitted, is to permit only a subset of HTML. I have a bulletin board created for internal use only that does this because I didn't care to make some kind of BB code and because the WYSIWYG editor I used created HTML output by default and I didn't want to tweak that.

I used the function strip_tags which is nice and simple. That's a lie really because what I used mimicked the way strip_tags works by parsing the data and also stripping unwanted attributes from tags (unweildy style attributes, javascript things, etc). But this is a simple way to quickly implement that functionality.

Alternatively, with what you've got, simply calling html_entity_decode on the values you get back from your MySQL queries should give you the HTML you want.

Actually its not pointless if hes allowing users to post their own html. Adds to a little anti sql-injection. There is no need to decode whats put into the table. I'e wrote something similar to what hes doin, never had a problem. My guess is there is a problem in the script. But since he wont post it, we cant tell.

[jMerliN]

Actually its not pointless if hes allowing users to post their own html. Adds to a little anti sql-injection. There is no need to decode whats put into the table. I'e wrote something similar to what hes doin, never had a problem. My guess is there is a problem in the script. But since he wont post it, we cant tell.

You should never rely on htmlspecialchars to make any data "query safe". There's a function for that: mysql_real_escape_string. And it should be used on *ALL* user-generated input unless you subject it to a stringent regex before hand (regexes take more CPU power than this function, so use it instead of trying to secure input via a regex).

[lordvladek]

You should never rely on htmlspecialchars to make any data "query safe". There's a function for that: mysql_real_escape_string. And it should be used on *ALL* user-generated input unless you subject it to a stringent regex before hand (regexes take more CPU power than this function, so use it instead of trying to secure input via a regex).

I know this, I usually write my own query safe string, and use mysql escape string when querying it. Its still better practice to be safe rather then sorry. Although yes, I do understand how you could have taken what I said the wrong way because of what I said. But it had nothing to do with his question so I didn't think I needed to tell him how to write a sql-safe query.

[jMerliN]

I know this, I usually write my own query safe string, and use mysql escape string when querying it. Its still better practice to be safe rather then sorry. Although yes, I do understand how you could have taken what I said the wrong way because of what I said. But it had nothing to do with his question so I didn't think I needed to tell him how to write a sql-safe query.

There is nothing "safer" than mysql_real_escape_string... anything else is just butchering your input.

What's more technically correct is type validation for each column but there are nice functions for that (is_numeric, etc, and regexes for emails, phone numbers, etc etc).

[lordvladek]

I know this... But prevention isn't just base on you sql escape strings. Its based on securing. A good ammount of your scripts will get butchered at one point or another for either validation or testing purposes. Wether it be with explode, implode, or just writing your own function to break it down. Saying that just using sql escape strings will save you from injection (Imho) is false. There are multiple ways of doing it. And technically speaking no, there is no one function safer the escape string. But you can lessen your chances by writing your own functions for validation and mixing it with escape string. Thats my point I'm trying to get across.

[jMerliN]

I know this... But prevention isn't just base on you sql escape strings. Its based on securing. A good ammount of your scripts will get butchered at one point or another for either validation or testing purposes. Wether it be with explode, implode, or just writing your own function to break it down. Saying that just using sql escape strings will save you from injection (Imho) is false. There are multiple ways of doing it. And technically speaking no, there is no one function safer the escape string. But you can lessen your chances by writing your own functions for validation and mixing it with escape string. Thats my point I'm trying to get across.

That won't lessen the chances. Traditional SQL injection simply cannot be done if it is escaped properly.

[s-p-n]

Just use mysql_real_escape_string() before it goes into the DB, and use stripslashes() when it comes out of the DB. Don't let the end-user put HTML covered data in your DB. You can use strip_tags() to resolve that problem. On Admin submitted data in the DB, you can allow HTML. It's very common. Don't worry about html_entity_decode, or html_entites, or htmlspecialchars, or htmlspecialcharsdecode. Again, just use mysql_real_escape_string() before it goes into the DB, and use stripslashes() when it comes out of the DB.

Edit: You can use htmlspecialcharsdecode() on the string to fix your current problem. I would run everything that had htmlspecialchars through a loop and update them with htmlspecialcharsdecode(). Of course, run mysql_real_escape_string() while updating the columns. That way stripslashes() is in sync with it. Sometimes you'll put slashes that you want, and stripslashes() will take too much off. So you want things in sync with each other for a complete system. (Leaves less bugs later on)

[xiaochris]

Hi,

The reason your file not doing the 'echo' command, could it be because your file is a .html file ? if it is , you should change it to a .php file.