7 Weitere Fehler, die üblicherweise von PHP -Entwicklern gemacht werden

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.

Key Takeaways

• Vermeiden Sie die veraltete MySQL -Erweiterung für SQL -Datenbanken, da sie unsicher, unzuverlässig ist und die Unterstützung für SSL und moderne MySQL -Funktionen nicht unterstützt. Entscheiden Sie sich stattdessen für Alternativen wie MySQLI oder PDO, die eine bessere Sicherheit und mehr Funktionen bieten.
• Vermeiden Sie die Unterdrückung von Fehlern in Ihrem Code, indem Sie den @ -Operator verwenden. Lassen Sie stattdessen Fehler angemeldet und beheben Sie diese, indem Sie Ihren Code beheben. Dies hilft, die Integrität Ihrer Anwendung aufrechtzuerhalten und verhindert, dass Probleme ignoriert oder übersehen werden.
• Seien Sie vorsichtig, wenn Sie zu viele Informationen über Ihr Back-End-Setup enthüllen, insbesondere wenn Sie ein bekanntes Framework verwenden. Dies kann Ihre Anwendung potenziellen Angriffen aussetzen, wenn eine Sicherheitsanfälligkeit in diesem Framework entdeckt wird. Denken Sie auch daran, Entwicklungskonfigurationen beim Drücken der Produktion zu entfernen, um einen unbefugten Zugriff zu verhindern.

7 weitere Fehler PHP -Entwickler machen häufig

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.

1. Verwenden der MySQL -Erweiterung

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.

2. Nicht pdo

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.

3. URLs nicht umschreiben

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.

4. Fehler unterdrücken

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.

5. Zuweisen unter Bedingungen

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:

1. Verwenden Sie eine anständige IDE. Jede gute IDE (wie zum Beispiel Phpstorming) warn
Verwenden Sie "Yoda -Bedingungen". Sie werden diese in vielen beliebten Projekten sehen, sogar in großen Rahmenbedingungen. Durch den Vergleich (wie in, wenn ('value' = $ condition) {) {) werden schwächere IDEs auch das Problem bemerken. Einige betrachten die Yoda -Syntax ärgerlich und sinnlos, eine Lebensader, in der es keine geben sollte ("Seien Sie vorsichtiger mit Ihrem Code, verdammt"), aber für jeden - wenn es jemandem hilft, bin ich alles dafür. Wenn wir alle Elitisten wären, würden WordPress und Zend Framework nicht existieren.
Wenn Sie es einfach im Auge behalten, werden Sie einen Augenreflex entwickeln, um dies jedes Mal zu überprüfen, wenn Sie ihn schreiben. Alles was es braucht ist das Üben, aber es passiert sogar zu den besten Entwicklern und hier ist 1. und 2. nützlich.

6. Zu transparent

sagen, dass dies einige Kontroversen aufregen könnte, aber hier geht es trotzdem. Sofern Sie nicht 100% Vertrauen in die Entwickler des Framework haben oder keine hoch gewinnorientierten, mit hohen geschäftskritischen Anwendungen mit hoher Handel betreiben, sollten Sie sich immer bemühen, Ihre Back-End-Wege zu verdecken. Hilfe bei der Verhinderung von Angriffen, sollte eine Sicherheitsanfälligkeit dieses Rahmens entdeckt werden. Zum Beispiel:

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.

7. Entfernen Sie Entwicklungskonfigurationen nicht

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

entfernt haben können
Die Entwickler hätten iPs mit Whitelisted gestellt haben, um auf app_dev.php zugreifen zu lassen, so wie es standardmäßig funktioniert, es sei denn, Sie lockern diese Einschränkungen.

Jeder dieser Ansätze hätte alle Probleme vollständig verhindert. Denken Sie daran, dass Ihre Entwicklungskonfiguration bei der Produktion entweder vollständig unzugänglich ist oder nur zu einem witterhaften IPS -Satz zugänglich ist.

Schlussfolgerung

Wie denkst du über diese Liste? Deckt es gemeinsame Aspekte ab oder ist es zu esoterisch? Haben Sie einige häufigere Fallstricke, die die drei Beiträge insgesamt nicht erwähnt haben? Lassen Sie es mich in den Kommentaren unten wissen und wir werden den Beitrag aktualisieren, wenn Ihr Rat solide ist!

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!