Ich baue eine RoR-Site, und heute bekomme ich die Paginierung. Als ich es meinem Kollegen gezeigt habe, lautet seine erste Frage "Was passiert, wenn Sie den Querystring auf" "page = -1" setzen. Er starb mit einer Laufzeitausnahme (Fehler 500). Er schlug vor, dass das vor dieser Site definitiv behoben werden sollte geht irgendwo in der Nähe von live.
Ich stimme mit ihm nicht überein (hört mich an). Nun, ich war vier Monate im Web-Dev-Geschäft, also könnte ich mich sehr irren. Aber ich denke, das ist keine große Sache. Ich denke, solange solche Fehler kein Sicherheitsrisiko darstellen, sollten solche Dinge keine Priorität haben. Der einzige Weg, um diesen Fehler zu verursachen, ist, wenn Sie die Query-Zeichenfolge manuell bearbeiten, und, nun, Müll in Müll raus. Wenn Sie schlau genug sind, um zu wissen, dass Sie den Querystring bearbeiten können, sollten Sie schlau genug sein, ihm keine negative Zahl zu geben.
Wie ist der allgemeine Konsens über solche Dinge? Machen Sie die Site komplett idiotensicher, sodass Sie unabhängig von der Abfragezeichenfolge nie einen Fehler erzeugen? Lässt du die Dinge so lange gleiten, wie es funktioniert (und kein Sicherheitsrisiko darstellt)? Irgendwo in der Mitte?
EDIT: Irgendwie ist meine Frage nicht wirklich so gekommen, wie ich es beabsichtigt habe. Der Kern meiner Frage war, wo ich die Grenze zwischen proaktivem Korrigieren von Dingen und Nicht-Tun ziehen sollte. Wenn es zum Beispiel eine ungültige Eingabe in der get-Zeichenkette gibt, wäre es besser, einen geschmackvollen Fehler anzuzeigen, wie in den geposteten Antworten vorgeschlagen, oder zu versuchen, herauszufinden, was der Benutzer getan hat, und dies zu tun. Oder, als ein konkreteres Beispiel: Wenn ein Benutzer page = -1 in der get-Zeichenkette eingibt, wäre es besser still anzunehmen, dass sie page = 0 bedeutet, oder eine geschmackvolle Fehlerseite anzuzeigen, die etwas wie "ungültige Seite angegeben" sagt "?
Sie sollten alles überprüfen, was aus der Abfragezeichenfolge kommt. Wenn Sie eine ungültige Seitennummer erhalten, sollten Sie eine Fehlermeldung haben, die etwas eleganter ist als die Seite Error 500. Vielleicht ein sorry, bad request. Try this: <possible suggestions> . Es ist einfach nur schlampig und unprofessionell, wissentlich und absichtlich einen leicht zugänglichen Fehler auf einer Live-Site zu hinterlassen.
Sie sagen, Sie sind neu in Web-Apps, aber wenn Ihre vorherige Entwickler-Erfahrung andere GUI-Apps waren, die von der "allgemeinen Öffentlichkeit" (Nicht-Entwicklern, Nicht-Technikern) verwendet wurden, wäre es in Ordnung Stack-Traces zu haben in das Gesicht des Benutzers geworfen, wenn die App um sie herum auseinanderfällt? Meiner Erfahrung nach ist dies niemals wirklich akzeptabel.
Sie machen einige gute Punkte, aber eine falsche Abfragezeichenfolge kann viele Gründe haben. Zum Beispiel eine Verknüpfung zu einem Datensatz, der seitdem gelöscht wurde. Oder ein Google-Ergebnis, das auf eine Seite verweist, die im aktuellen Ergebnis nicht mehr vorhanden ist.
In diesen Fällen sollten Sie dem Benutzer etwas etwas ausführlicheres zeigen als einen Fehler von 500.
Ich glaube nicht, dass eine Seite mit 500 Fehlern für Ihren durchschnittlichen Benutzer sehr aussagekräftig ist. Sagen Sie ihm zumindest, dass etwas mit Ihrer Seite nicht stimmt, und führen Sie ihn zurück auf die richtige Fährte, indem Sie einen Link bereitstellen, um zu Ihrer Website zurückzukehren.
Manchmal leite ich Benutzer auf eine Seite um, die wahrscheinlich genau das ist, was er wollte. Wenn eine Abfrage unter Null geht und dies nicht zulässig ist, leiten Sie Ihren Benutzer an die Seite "page = 0" weiter und zeigen Sie möglicherweise eine Nachricht oben auf dieser Seite an. Ich denke, dass Sie diese Methode bevorzugen sollten, weil es ein besserer Ansatz in Bezug auf die Benutzererfahrung ist, keine modalen Fenster zu verwenden.
Es variiert von Projekt zu Projekt. Wie viele Nutzer erwarten Sie? Wenn es unter 10K Besucher pro Tag ist, ist es vielleicht nicht so schlimm. Wie viel Prozent der Nutzer erwarten das Problem? Ich erwarte nicht so viele, aber Sie würden es am besten wissen.
Das Ziel sollte sein, das Produkt zu versenden und Verbesserungen regelmäßig einzuführen. Hoffentlich ist das Produkt insgesamt solide.
Wenn eine Seite nicht gefunden wird, sollte anstelle einer 5xx ein 4xx-Fehler geworfen werden. 5xx-Fehler rechtfertigen normalerweise einen tieferen Blick und obwohl es schwierig ist, direkt beim Start eine luftdichte Anwendung zu schreiben, sollten Sie versuchen, einen generischen Handler für 4xx- und 5xx-Fehler zu haben.
Tags und Links html