php 5.4 naar 7.0
Hallo PHPHulp,
Ik maak gebruik van gratis hosting die binnenkort php 5.4 niet meer ondersteund en overgaat naar 7.0 (je kunt nog wel kiezen uit 5.6) Maar mijn vraag is als ik 7.0 aanzet dan zie ik allemaal errors met mysql en meer. Aangezien dit een lange topic wordt aangezien er meerdere delen van een script aan bot komt.
1ste error. Toevoeging:
Error 1:
Mijn eerste error is
Dit is mijn source: (config.php)
Ik denk zelf dat ik van 2 rijen naar 1 moet gaan zoiets als dit:
Ik maak gebruik van gratis hosting die binnenkort php 5.4 niet meer ondersteund en overgaat naar 7.0 (je kunt nog wel kiezen uit 5.6) Maar mijn vraag is als ik 7.0 aanzet dan zie ik allemaal errors met mysql en meer. Aangezien dit een lange topic wordt aangezien er meerdere delen van een script aan bot komt.
1ste error. Toevoeging:
Error 1:
Mijn eerste error is
Code (php)
1
2
3
4
2
3
4
Fatal error: Uncaught Error:
Call to undefined function mysql_connect() in /home/prive/public_html/members_area/config.php:12
Stack trace: #0 /home/prive/public_html/members_area/index.php(2):
include() #1 {main} thrown in /home/prive/public_html/members_area/config.php on line 12
Call to undefined function mysql_connect() in /home/prive/public_html/members_area/config.php:12
Stack trace: #0 /home/prive/public_html/members_area/index.php(2):
include() #1 {main} thrown in /home/prive/public_html/members_area/config.php on line 12
Dit is mijn source: (config.php)
Code (php)
1
2
2
mysql_connect('localhost', 'gebruikersnaam', 'wachtwoord');
mysql_select_db('database');
mysql_select_db('database');
Ik denk zelf dat ik van 2 rijen naar 1 moet gaan zoiets als dit:
Gewijzigd op 19/02/2016 20:30:51 door Tim Wolf
De standaard MySQL driver (dit omvat alle mysql_* functies) bestaat niet meer in PHP 7.0. Je zult moeten overstappen naar MySQLi of PDO. Dit wordt ook hoog tijd, want dit wordt al circa ~10 jaar aanbevolen.
Dus dit is goed?:
@Tim Wolf: Ja, maar de voorkeur gaat meestal naar de OO MySQLi.
Maar kwa verschil van resultaat zal het niet uitmaken.
Maar kwa verschil van resultaat zal het niet uitmaken.
Tim Wolf op 19/02/2016 21:53:23:
Ja, maar zeker niet de enige stap. Alle functies moet je herschrijven naar mysqli. Vaak gaat dit gepaard met een extra argument die naar je connectie verwijst.
Ikzelf raad de MySQLi-OO variant aan.
hmmm hmmm OOP ja. Dit staat overigens voor Object Oriented Programming. Maarrrrr als de hele PHP code Procedural geschreven is dan is dit ook een beetje een vlag op een str*ntschuit :-)
Indien Tim aardige ervaring heeft opgebouwd met Procedural code en geen ervaring heeft met OOP dan zou ik zeker de Procedural manier aanraden.
Indien Tim aardige ervaring heeft opgebouwd met Procedural code en geen ervaring heeft met OOP dan zou ik zeker de Procedural manier aanraden.
Mijn hele CMS was nog procedureel geschreven, maar een half jaartje geleden zag ik in dat alles eens maar MySQLi-OO moet gaan, en ben ik alles aan het verbouwen naar OO. ;-)
Hoop werk, maar foutafhandeling kan je op deze manier meteen integreren in je $db->query("......");
Hoop werk, maar foutafhandeling kan je op deze manier meteen integreren in je $db->query("......");
Gewijzigd op 19/02/2016 23:04:08 door - Ariën -
Inderdaad Ariën.
Maar nu heb alles van mysql connect naar mysqli connect gezet. Werkt goed maar nu kom ik bij ht volgende:
en
en
Als ik daar mysqli_real_escape_string van maak geeft hij de eerste error aan:
Warning: mysqli_real_escape_string() expects exactly 2 parameters, 1 given
hetzelfde met:
Warning: mysqli_fetch_array() expects parameter 1 to be mysqli_result, null given in
Maar nu heb alles van mysql connect naar mysqli connect gezet. Werkt goed maar nu kom ik bij ht volgende:
en
en
Als ik daar mysqli_real_escape_string van maak geeft hij de eerste error aan:
Warning: mysqli_real_escape_string() expects exactly 2 parameters, 1 given
hetzelfde met:
Warning: mysqli_fetch_array() expects parameter 1 to be mysqli_result, null given in
Gewijzigd op 20/02/2016 11:42:26 door Tim Wolf
Je zet je mysqli_connect in een variabele
bv:
je mysqli_real_escape_string wordt dan:
Zie: http://php.net/manual/en/mysqli.real-escape-string.php
bv:
je mysqli_real_escape_string wordt dan:
Zie: http://php.net/manual/en/mysqli.real-escape-string.php
Gewijzigd op 20/02/2016 11:49:00 door Shamrock Modelbouw
Dat zei ik dus ;-)
Quote:
Ja, maar zeker niet de enige stap. Alle functies moet je herschrijven naar mysqli. Vaak gaat dit gepaard met een extra argument die naar je connectie verwijst.
Neeeeeeee....
Het eerste stukje klopt, met de variabele waarin je de connectie link maakt.
Maar die stripslashes moet er uit. Je escaped, dat wil zeggen dat er (onzichtbare)slashes worden toegevoegd.
Dat is om te escapen op kwaadwillende karakters. Vervolgens ga je die om zeep helpen met stripslashes dus dat moet eruit.
EDIT nog een betere uitleg:
Een string die je door _escape_string() haalt ziet er zo uit:
"Ik heb een nieuwe fiets.\n En bart\'s fiets is al 20 jaar oud."
als je stripslashes gebruikt dan haal je die \ weg en dan heb je het zelfde als dat je geen _escape_string() gebruikt.
Dus:
"Ik heb een nieuwe fiets. En bart's fiets is al 20 jaar oud."
En dan is ie lek, en gevoelig op een sql injection. want dan kan je na de ' dus iets erbij zetten. Daarom geen stripslahes..
Het eerste stukje klopt, met de variabele waarin je de connectie link maakt.
Maar die stripslashes moet er uit. Je escaped, dat wil zeggen dat er (onzichtbare)slashes worden toegevoegd.
Dat is om te escapen op kwaadwillende karakters. Vervolgens ga je die om zeep helpen met stripslashes dus dat moet eruit.
EDIT nog een betere uitleg:
Een string die je door _escape_string() haalt ziet er zo uit:
"Ik heb een nieuwe fiets.\n En bart\'s fiets is al 20 jaar oud."
als je stripslashes gebruikt dan haal je die \ weg en dan heb je het zelfde als dat je geen _escape_string() gebruikt.
Dus:
"Ik heb een nieuwe fiets. En bart's fiets is al 20 jaar oud."
En dan is ie lek, en gevoelig op een sql injection. want dan kan je na de ' dus iets erbij zetten. Daarom geen stripslahes..
Gewijzigd op 20/02/2016 12:30:16 door Bart V B
Volgens mij niet Bart, stripslashes() wordt éérst uitgevoerd, en dan pas de real_escape_string functionaliteit. Wat hier dus uiteindelijk uitkomt is veilig (of liever gezegd, veiliger, zie kanttekening hieronder) in de MySQL-context mits je character encoding klopt.
Overigens worden er ook al enige tijd geen backslashes meer automatisch toegevoegd aan waarden van superglobal variabelen, omdat magic_quotes_gpc ook (en al eerder) is verdwenen (verwijderd vanaf PHP 5.4.0). Het enige "gevaar" met het gebruik van stripslashes -sinds het verdwijnen van magic_quotes_gpc- is dus dat er mogelijk teveel backslashes worden verwijderd uit de invoer, die echt onderdeel uitmaakten van de invoer, en niet (per definitie) bedoeld waren voor escaping.
EDIT: cruciale kanttekening: het is pas echt veilig als het ge-real_escape-te deel tussen (enkele) quotes in je query staat. Alleen deze combinatie is veilig. Het een is niet veilig zonder het ander want real_escape_string escapet alleen maar gevaarlijke karakters. Als invoer geen gevaarlijke karakters bevat, bijvoorbeeld:
41 OR 1 = 1
Dan escapet real_escape_string niets omdat er niets te escapen valt!
real_escape_string is dus geen wondermiddel, je moet hier nog steeds voorzichtig mee omgaan!
Overigens worden er ook al enige tijd geen backslashes meer automatisch toegevoegd aan waarden van superglobal variabelen, omdat magic_quotes_gpc ook (en al eerder) is verdwenen (verwijderd vanaf PHP 5.4.0). Het enige "gevaar" met het gebruik van stripslashes -sinds het verdwijnen van magic_quotes_gpc- is dus dat er mogelijk teveel backslashes worden verwijderd uit de invoer, die echt onderdeel uitmaakten van de invoer, en niet (per definitie) bedoeld waren voor escaping.
EDIT: cruciale kanttekening: het is pas echt veilig als het ge-real_escape-te deel tussen (enkele) quotes in je query staat. Alleen deze combinatie is veilig. Het een is niet veilig zonder het ander want real_escape_string escapet alleen maar gevaarlijke karakters. Als invoer geen gevaarlijke karakters bevat, bijvoorbeeld:
41 OR 1 = 1
Dan escapet real_escape_string niets omdat er niets te escapen valt!
real_escape_string is dus geen wondermiddel, je moet hier nog steeds voorzichtig mee omgaan!
Gewijzigd op 20/02/2016 15:12:13 door Thomas van den Heuvel
Ik laat er wel een prof naar kijken.
Bedankt!
Bedankt!
Je heb ook een tool waarmee je bestanden en of complete folders met alle bestanden in een keer kunt omzetten van mysql naar mysqli.
MySQLConverterTool
MySQLConverterTool
Mausie Wausie op 21/02/2016 11:59:22:
Je heb ook een tool waarmee je bestanden en of complete folders met alle bestanden in een keer kunt omzetten van mysql naar mysqli.
MySQLConverterTool
MySQLConverterTool
Nice bedankt! Hier heb ik wat aan!
Zoals eerder aangegeven, mogelijk zorgen de voorkomens van stripslashes ervoor dat er teveel gestript wordt. Dit stamt nog uit een tijdperk dat er aan de superglobals ($_GET, $_POST, $_COOKIE) automagisch extra slashes werden toegevoegd middels magic_quotes_gpc (en dit was niet eens vanwege security, maar meer vanuit gebruikersgemak). Deze voorziening is inmiddels verdwenen. Indien je de voorkomens van stripslashes() dan niet ook verwijdert, worden er mogelijk teveel slashes gestript uit je invoer.
Ik zou in dit geval zeker niet blindelings vertrouwen in zo'n tool, maar je code (op zijn minst ook) goed doortesten met verschillende invoer.
Ik zou in dit geval zeker niet blindelings vertrouwen in zo'n tool, maar je code (op zijn minst ook) goed doortesten met verschillende invoer.
Gewijzigd op 21/02/2016 15:12:51 door Thomas van den Heuvel
Thomas van den Heuvel op 21/02/2016 14:50:12:
Zoals eerder aangegeven, mogelijk zorgen de voorkomens van stripslashes ervoor dat er teveel gestript wordt. Dit stamt nog uit een tijdperk dat er aan de superglobals ($_GET, $_POST, $_COOKIE) automagisch slashes werden toegevoegd middels magic_quotes_gpc. Deze voorziening is inmiddels verdwenen. Indien je de voorkomens van stripslashes() dan niet ook verwijderd, worden er mogelijk teveel slashes gestript uit je invoer.
Ik zou in dit geval zeker niet blindelings vertrouwen in zo'n tool, maar je code (op zijn minst ook) goed doortesten met verschillende invoer.
Ik zou in dit geval zeker niet blindelings vertrouwen in zo'n tool, maar je code (op zijn minst ook) goed doortesten met verschillende invoer.
Klopt wordt bij de tool ook aangegeven: "Note that absolutely no security checks are performed", lijkt mij ook dat je dit zelf doet.
Security is ook een factor, maar ik had het hier meer over mogelijk ongewenste manipulatie/verminking van je invoer. Uiteraard dient de invoer zowel volledig (en (dus) ongewijzigd) en veilig worden aangeboden aan de database. Maar dit zijn echt twee verschillende dingen.




