Ende Juni veröffentlichte Toptal, der freiberufliche Marktplatz, einen Beitrag über 10 häufigste Fehler, die PHP -Programmierer machen. Die Liste war nicht erschöpfend, aber sie war gut geschrieben und wies auf einige sehr interessante Fallstricke hin, vor denen man vorsichtig sein sollte - selbst wenn ich die Fehler nicht persönlich als sehr häufig auflisten würde.
Ich ermutige Sie, ihm gründlich zu lesen - es gibt einige wirklich wertvolle Informationen, die Sie kennen sollten - insbesondere die ersten acht Punkte. Vor ein paar Tagen erweiterte Anna Filina auf der Liste mit sieben neuen Einträgen. Obwohl sie weniger spezifisch und häufig sind, tragen ihre Punkte immer noch Gewicht und sollten bei der Entwicklung berücksichtigt werden.
Ich wurde von jemandem von Toptal gebeten, einen Blick auf seine Liste zu werfen und potenziell einen Beitrag zu leisten, und einige unserer Follower in sozialen Netzwerken haben ein Interesse daran geäußert, die Liste weiterzumachen. Ich möchte diese Gelegenheit dazu nutzen Fügen Sie dieser Liste einige meiner eigenen Einträge hinzu, die ich wiederholt meine Teammitglieder oder Follower warnen muss.
Diese Nachrichten sind ziemlich alt, aber die Anzahl der Entwickler, die sich der Tatsache nicht bewusst sind, ist besorgniserregend. Bei Verwendung von SQL -Datenbanken, insbesondere von MySQL, entscheiden sich viel zu viele Entwickler immer noch für die MySQL -Erweiterung. Die MySQL -Erweiterung ist offiziell veraltet. Es ist unsicher, unzuverlässig, unterstützt SSL nicht und fehlt einige moderne MySQL -Funktionen. Es generiert auch Abschaltungsnotizen, die Ihre App nicht brechen, sie werden nur ganz oben in Ihrer App angezeigt. Es bedeutet, dass dies auch sehr möglich ist, einfach für all die verschiedenen Websites zu googeln, die dieses unsichere Setup verwenden, indem sie einfach danach suchen. Die Welt der Verletzungen, denen diese Apps aufgrund dieses Chaos ausgesetzt sind, ist erstaunlich.
Anstatt MySQL zu verwenden, entscheiden Sie sich für eine der Alternativen: Mysqli oder PDO. Zum Beispiel ist die Verwendung von MySQLI stattdessen fast so einfach wie das Hinzufügen des Buchstabens „I“ zum Ende der API -Aufrufe:
<span>$c = mysql_connect("host", "user", "pass");
</span><span>mysql_select_db("database");
</span><span>$result = mysql_query("SELECT * FROM posts LIMIT 1");
</span><span>$row = mysql_fetch_assoc($result);</span>vs
<span>$mysqli = new mysqli("host", "user", "pass", "database");
</span><span>$result = $mysqli->query("SELECT * FROM posts LIMIT 1");
</span><span>$row = $result->fetch_assoc();</span>Das ist alles, was es brauchte, um das Setup unermesslich sicherer zu machen.
Sie sollten sich jedoch für PDO entscheiden. Mehr dazu in Punkt 2.
Versteh mich nicht falsch, Mysqli ist (im wahrsten Sinne des Wortes) Generationen vor der alten MySQL -Erweiterung. Es ist auf dem Laufenden, sicher, zuverlässig und schnell auf dem Laufenden gehalten. Es ist jedoch mySQL spezifisch. Mithilfe von PDO können Sie eine wunderbar praktische objektorientierte Syntax verwenden und Sie auf Tango mit anderen SQL -Datenbanken wie PostgreSQL, MS SQL und mehr vorbereiten. Darüber hinaus können Sie mit PDO die benannten Parameter verwenden, eine Funktion, die so nützlich ist, dass nur wenige Menschen sich vorstellen können, nach etwas anderem zu gehen, nachdem sie den richtigen Vorteil haben. Last but not least gibt es Folgendes: Sie können abgerufene Daten direkt in ein neues Objekt einfügen, was in großen Projekten ein entzückender Zeitverstand ist.
Ein weiterer allgemein ignorierter und leicht zu behebendes Problem. URLs wie myapp.com/index.php?p=34&g=24 sind heutzutage einfach nicht akzeptabel. Da es unglaublich schwierig ist, einen guten URL -Umschreibungshandbuch zu schreiben, der jeden Server und jeden Framework abdeckt, hat fast jedes Framework eine Anleitung zum Einrichten sauberer URLs (Laravel, Phalcon, Symfony, Zend) und jeglicher, die Don ' Es ist sich nur nicht wert - sie kümmern sich offensichtlich nicht um moderne Praktiken.
Ich habe in einem früheren Artikel darüber geschrieben, aber es ist wieder erwähnenswert. Jedes Mal, wenn Sie den @ -Operator verwenden, überdenken Sie das Problem aus einem anderen Blickwinkel aus und nähern Sie sich genauer. Nehmen Sie mein Wort dafür, wenn ich sage, dass 20 Zeilen von Boilerplate -Curl -Code um die Funktionen einer App besser sind als eine einzelne Zeile mit dem @ -Operator davor.
Ich habe durch persönliches Experimentieren festgestellt, dass ein guter Ansatz derjenige ist, den ich im ursprünglichen Beitrag befürworte - alle Ihre Hinweise in tödliche Fehler verwandeln. Stellen Sie sicher, dass nichts in die Fehlerprotokolle eingeloggt wird, da es buchstäblich nichts gibt. Wir haben kürzlich einige Heroku-Add-Ons für produktionsbereite PHP-Apps behandelt, und eines davon war der ausgezeichnete Papertrail-ein Add-On, mit dem Sie alle Fehler Ihrer App zu ihrem Backend für einfacher suchen, gruppieren und später beseitigen können An; Selbst wenn einige Fehler auftreten, ist es besser, sie protokolliert zu lassen und sie zu entfernen, indem sie Ihren Code reparieren, als sie zum Schweigen zu bringen und vor Ihren Benutzern dumm zu spielen.
sogar erfahrene Entwickler haben manchmal einen Fingerrutschen und schreiben Sie, wenn ($ condition = 'value') {anstelle von if ($ condition == 'value') {. Unsere Hände werden ausrutschen, unsere Tastaturen registrieren nicht den Schlüsselpress, wir werden am Ende von einem anderen Teil des Codes einfügen, in dem die Aufgabe tatsächlich passiert ist - dies passiert, und wir finden normalerweise nur, wenn wir die App ausführen.
Es gibt verschiedene Möglichkeiten, dies vollständig zu vermeiden:
Wenn Sie Symfony2 -Übersetzer verwenden und jetzt eine Route mit einem {_locale} -Parameter -Upgrade haben! http://t.co/jihxhb8mzt - Jérémy Derusse (@jderusse) 15. Juli 2014
In diesem Tweet wird Kenntnis eines ernsthaften Problems der Code -Injektion in öffentlichem Domäne übertragen. Dies ist großartig, wenn Sie am Arbeit sind und sofort ohne DevOps -Probleme aufrüsten können und das Team zuerst zusammenarbeiten lassen, aber für die meisten Menschen und Unternehmen, die Symfony verwenden, ist dies nicht der Fall. Auch wenn Symfony über Komponist verbessert werden kann (wie Ryan in den Kommentaren unten erwähnt), dauert es normalerweise eine Weile, bis große Teams mit mehrstufigen Umgebungen die Genehmigung erhalten. Alle Websites, die diesen Übersetzeransatz verwenden, der zu deklariertem Symfony -Nutzern (sind?), Daher wurden diese Sicherheitsanfälligkeit bis festgesetzt.
Symfony im obigen Beispiel war genau das - ein Beispiel. Ähnliche Situationen sind im Laufe der Jahre mit unzähligen anderen Software entstanden. Als ich Zend Framework immer noch kommerziell benutzte, hatten wir dies auch geschehen und erlitten einen Angriff. WordPress hat seinen Anteil an Sicherheitsgaffes gehabt und wir wissen, wie hoch ein Prozentsatz der Websites da draußen ist. Diese Dinge passieren und manchmal sind Open Source und Transparenz nicht der beste Ansatz, wenn Sie sich mit Anwendungen befassen, die die Mehrheit des Umsatzstroms eines Unternehmens tragen.
Last but not least sollte die Entfernung der Entwicklungskonfiguration erwähnt werden. Vor kurzem (und es ist ein ehrlicher Zufall, den ich hier wieder Symfony erwähne) hat CNET einen Angriff erlitten, weil sie ihre Entwicklungskonfiguration nicht beseitigt.
Uhmmm Nr.
CNET, eine der weltweit größten Tech -Nachrichtenseiten, basiert auf Symfony. Symfony enthält, wie Sie vielleicht wissen, zwei Einstiegspunkte für Ihre Anwendung: app.php und app_dev.php. Indem Sie Ihren Browser auf einen zeigen, erhalten Sie die Produktionsumgebung. Indem Sie auf das mit dem _DEV -Suffix hinweisen, erhalten Sie offensichtlich die Entwicklungsversion, die einen Debugger, sensible Daten und mehr enthält. Ob dies gut oder schlecht ist, ist ein Thema vieler Diskussionen (dank Ryan, dass sie dies darauf hingewiesen haben), aber es ist unbestreitbar, dass es einige Clumsier -Entwickler für Fehler wie die CNET eröffnet. Darüber hinaus wird auf andere URLs auf app_dev zugegriffen. Mit anderen Worten, es ist nicht nur die Indexseite, die im Entwicklungsmodus startet, sondern die gesamte Website - im Fall von CNET ist das viel Zugriff.
Wenn Sie der Diskussion auf Twitter folgen, wird es sehr schnell traurig - und was noch trauriger ist, dass es in der Arbeit einer zweiten hätte vermieden werden können:
Die Entwickler hätten app_dev.php von den Produktionsservern
Schlussfolgerung
Das obige ist der detaillierte Inhalt von7 Weitere Fehler, die üblicherweise von PHP -Entwicklern gemacht werden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Einstellungen der Java-Umgebungsvariablen
So löschen Sie leere Seiten in Word
So öffnen Sie die WeChat-HTML-Datei
So verwenden Sie Spyder
Worauf bezieht sich „Schreiben' in Python?
Timeout-Lösung für Serveranfragen
Kann ich ein gelöschtes Douyin-Kurzvideo wiederherstellen?
Welche Software ist Openal?
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
