Ist es eine schlechte Methode, interne DB-IDs in URLs verfügbar zu machen?

Question

Ist es eine schlechte Methode, interne DB-IDs in URLs verfügbar zu machen?

Angenommen, ich habe eine users Tabelle mit einigen IDs (Primärschlüssel) für jede Zeile. Wird die URL myapp.com/accountInfo.html?userId=5, wo 5 ein echter Primärschlüssel ist, als "schlechte Sache" betrachtet und warum?

Gehen Sie auch davon aus, dass wir SQL-Injektionen richtig abwehren.

Ich bin vor allem an Antworten interessiert, die sich auf den Java-Webtechnologie-Stack beziehen (daher der Java-Tag), aber allgemeine Antworten werden auch sehr hilfreich sein.

Danke.

Answer 1

Das basiert auf der Art, wie Sie die URL analysieren. Wenn Sie blinde SQL-Injektionen zulassen, ist das schlecht. Sie müssen nur die ID von der Benutzereingabe validieren.

Stackexchange fügt auch die ID der Zeile in die URL ein, wie Sie in Ihrer Adressleiste sehen können. Der Trick besteht darin, den Teil zu analysieren und alles mögliche SQL zu bekommen. Der einfache Weg besteht darin, zu überprüfen, ob die ID eine Zahl ist.

Answer 2

Es ist keine schlechte Sache in der URL zu passieren, da es nicht viel für den Endbenutzer bedeutet - es ist nur schlecht, wenn Sie auf diesen Wert in der Ausführung Ihrer Anwendung verlassen. Zum Beispiel möchten Sie nicht, dass der Benutzer diese userId = 5 bemerkt und ändern Sie ihn in userID = 10, um den Account einer anderen Person anzuzeigen.

Es wäre viel sicherer, diese Informationen in einer Sitzung auf dem Server zu speichern. Wenn sich der Benutzer zum Beispiel anmeldet, wird sein Benutzer-ID-Wert in der Sitzung auf dem Server gespeichert, und Sie verwenden diesen Wert immer dann, wenn Sie die Datenbank abfragen. Wenn Sie dies auf diese Weise tun, ist es normalerweise nicht erforderlich, die Benutzer-ID in der URL zu übergeben. Es würde jedoch nicht schaden, da sie nicht von Ihrem DB-Abfragecode verwendet wird.

Answer 3

Die Verwendung der Datenbank-ID in URLs ist gut, weil diese ID niemals in einem Objekt (DB-Zeilen) Leben ändern sollte. Somit ist die URL dauerhaft - der wichtigste Aspekt einer URL. Siehe auch Cool URIs don't change.

Answer 4

Ja, es ist eine schlechte Sache. Sie legen das Implementierungsdetail offen. Wie schlimm? Das hängt davon ab. Es zwingt Sie zu unnötigen Überprüfungen der Benutzereingaben. Wenn andere Anwendungen davon abhängig sind, können Sie das Datenbankschema nicht mehr ändern.

Answer 5

PKs sind für das System gedacht.
Für den Benutzer kann es eine andere Bedeutung darstellen:
Für z.B. Betrachten wir folgende Links. Mit dem Primärschlüssel wird ein Artikel unter Produkte
ProduktA, ProduktB, ProduktC angezeigt;

(A)http://blahblahsite.com/browse/productA/111 (pTaste)
(B)http://blahblahsite.com/browse/productB/112 (pTaste)
(C)http://blahblahsite.com/browse/productC/113 (pTaste)
Benutzer den Link B es Elemente gibt 112 fühlen unter ProductB, was irreführend ist.

Es wird auch Probleme beim Zusammenführen von Tabellen verursachen, da PK automatisch inkrementiert wird.