Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 20 of 20
  1. #16
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,987
    Thanks
    4
    Thanked 2,660 Times in 2,629 Posts
    Taking the topic back slightly: you certainly can store data that has been cleaned for XSS prior to inserting it. If that is your ruleset that is. Typically I recommend storing it as raw as it was provided, and dealing with the html quirks at runtime (during the selection process). But it all depends on your rules. if you allow someone to have a username that is <Script>, then you don't really want to not store it in its entirety. Simply use HTML entities during the display process instead. Bring the concept of the datastorage up from being a web thing to being a data thing. If I want to print reports instead of displaying in HTML, then the meaning of the characters will change, so I'd suggest keeping them raw is the best solution for cross usage.

    MySQL should actually perform a slight bit better than MySQLi I would expect. Although it is lacking most of what makes MySQLi so awesome, so I wouldn't suggest that the trivial performance difference should be considered as a weighing factor in which you choose (ie: choose MySQLi from the two ). I haven't read anything official on removal of MySQL support (at least I don't think I have. . .), and its not listed as deprecated as of yet. But no I wouldn't be surprised if it just ups and disappears on 6.0 release.

  2. #17
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,627
    Thanks
    0
    Thanked 648 Times in 638 Posts
    Quote Originally Posted by angelali View Post
    I have never said strip_tags and htmlentities are used for database! I said I used them against XSS. Read again.
    They have nothing to do with XSS or SQL injection - they have to do with converting VALID data into an appropriate format where it might conflict with code.


    If you were doing everything properly in the first place then XSS and SQL injection would not even be an issue.

    You need to learn how to VALIDATE user data and then 99% of all the security issues will disappear leaving just those situations where the data might legitimately be confused with the code - then you use the appropriate ESCAPE function in those instances not to prevent security holes but to get legitimate data to work correctly.

    With VALID data that is appropriately ESCAPED when necessary there is no such thing as XSS or SQL injection. Those issues only exist where you allow junk data to be input in the first place and then even if you do block the security holes it will still be possibler for someone to write a trillion junk records to your database making your entire application useless.


    Anyone concerned with XSS or SQL injection is looking at the entire situation backwards and is simply asking for someone to fill their database with junk AFTER they have fixed any SQL injection issues - since fixing those issues doesn't mean that the data is VALID.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  3. #18
    Regular Coder
    Join Date
    Nov 2012
    Posts
    115
    Thanks
    7
    Thanked 12 Times in 12 Posts
    Quote Originally Posted by Fou-Lu View Post
    I haven't read anything official on removal of MySQL support (at least I don't think I have. . .), and its not listed as deprecated as of yet. But no I wouldn't be surprised if it just ups and disappears on 6.0 release.
    http://php.net/manual/en/faq.databas...sql.deprecated
    Quote Originally Posted by PHP.net
    The old API should not be used, and one day it will be deprecated and eventually removed from PHP. It is a popular extension so this will be a slow process, but you are strongly encouraged to write all new code with either mysqli or PDO_MySQL.
    http://news.php.net/php.internals/53799
    Quote Originally Posted by PHP.net
    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the situation
    So no, not officially deprecated yet, but not far off.

  4. #19
    Regular Coder
    Join Date
    Dec 2010
    Location
    London
    Posts
    338
    Thanks
    63
    Thanked 11 Times in 11 Posts
    I have a site that uses the old mysql for all of it's connections. I'm planning on upgrading this to mysqli or PDO when I get the time, but is it going to be a case that my site will just stop working once they remove the support for it?

  5. #20
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,627
    Thanks
    0
    Thanked 648 Times in 638 Posts
    Quote Originally Posted by paddyfields View Post
    I have a site that uses the old mysql for all of it's connections. I'm planning on upgrading this to mysqli or PDO when I get the time, but is it going to be a case that my site will just stop working once they remove the support for it?
    When your hosting provider upgraded PHP to a version where that interface no longer exists your site will stop working.

    That's why they give plenty of advanced warning of what is going to be removed in the future so that everyone has lots of time to upgrade to use the replacement.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.


 
Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •