Welcome Guest, Not a member yet? Register   Sign In
escape html-entities
#1

[eluser]sl3dg3hamm3r[/eluser]
Hey there

Form-validator offers to escape html-entities. But is this actually right to escape these stuff before writing to the database? Isn't it rather best practice to store input as it is and escape it after?

If yes, the db-layer doesn't offer any functionality for html-escaping, right? As for me, I didn't find anything like that in the docs.

Sl3dg3
#2

[eluser]sl3dg3hamm3r[/eluser]
According to another developer-forum I was confirmed that user-input should be better stored unescaped (or let's say, untouched) into the database. Therefore it would be a nice feature for the active record class to have an option which would directly escape the html-entities, what do you think?

Sl3dg3
#3

[eluser]drewbee[/eluser]
I agree with this practice completely. I do not like touching user data going in, but fixing it on the way out. If you change it on the way in, it makes it that much harder to track and debug.

Also, the following scenario may offer advice on why you would do this.

Lets say you have a database column VARCHAR with a maxlength of 10.

Now lets say through a form the user inputs the following: 'go>to>here'

So the above is 10 characters correct? Nope. Not after escaping it.

What would be inserted into the database is 'go>to>' at its 10 character limit, obviously ommiting a very important section of the string.

Hope this helps...
#4

[eluser]sl3dg3hamm3r[/eluser]
Thank you for your thoughts. Maybe I should post the entity-encoding as a wished feature (in the active record class).
#5

[eluser]drewbee[/eluser]
No you got it backwards. You don't want to entity encode going into the database Smile Unless you are talking about the part coming back out. CI's form validation class takes care of this though with the set_value, set_radio, set_select, set_checkbox functions (form helper).
#6

[eluser]sl3dg3hamm3r[/eluser]
[quote author="drewbee" date="1225310906"]Unless you are talking about the part coming back out.[/quote]

Yes I was talking about this part. It would be nice to have everything ready without any further thinking (and forgetting) about html-escaping, wouldn't it? Smile

Well, would actually be a classical case for a decorator-pattern, a class which 'decorates' the active record pattern, in this case it would add the html-entities.
#7

[eluser]callumd[/eluser]
The one benefit of converting text in to HTML entities *prior* to going in to the database is that your app will run faster. (You encode the HTML entities only once this way, as opposed to having convert the data in to HTML entities each and every time you pull it from the database).

Whether this would be considered a really bad practice for other reasons, I'm not sure.
#8

[eluser]drewbee[/eluser]
I personally would consider it bad practice, just even for the simple example I gave above.

Personally I would stay away from a decorator type of deal as for the case when you actually do not want to convert data from the database. CI has some built in functions to handle this coming out. I prefer to set this all in the view regardless so in the view I have control over what gets escaped and not. I'm sure it wouldn't be that hard to put in as an extension to the current library.
#9

[eluser]Colin Williams[/eluser]
I also see no reason for the database classes to do this. This is data modeling, so it should happen in the Model, probably right after it is retrieved.
#10

[eluser]sl3dg3hamm3r[/eluser]
good point. maybe i rather implement a model / library taking over this part.




Theme © iAndrew 2016 - Forum software by © MyBB