Probleme beim URL routen

[MB]

moin Community,

welchne möglichkeiten gibt es zum URL Router also controller->action->params weitere Attribute in der URLintegrieren? z.B. Sprache, Rechte.

Ich habe da eine statische Struktur im URL Router verwendet: lang -> user -> controller -> action -> params[]. Ich habe die Sprache die die angeforderte Seite haben muss sowie die Rolle des Benutzers in die URL integriert. Wenn eine angabe fehle dann leitet mein Router mit redirect um und ergänzt die URL, sodass man sehr schon anhand der URL sehen kann, wo man sich grade in einer Webseite befindet.

vlg MB

[Matthias Apsel]

Hallo MB,

welchne möglichkeiten gibt es zum URL Router also controller->action->params weitere Attribute in der URLintegrieren? z.B. Sprache, Rechte.

Rechte solltest du nicht über die URL abbilden.

Bis demnächst
Matthias

[MB]

Hi Matthias,

Rechte solltest du nicht über die URL abbilden.

ich meinte die Rolle.

vlg MB

[TS]

Hello,

Rechte solltest du nicht über die URL abbilden. ich meinte die Rolle.

Auch die nicht.

Siehe hierzu auch den Thread zum Referrer, der gerade erst gelaufen ist.

Frage:
Was steht im Referrer, wenn man aus einer HTTPs-Seite einen Link auf eine andere Seite aufruft? Stell Dir vor, Du hat eine Linksammlung und verlinkst daraus direkt (im Gegensatz zu Indirekt) auf die erwähnten Veröffentlichungen.

Selbst die Übermittlung eines Tokens (Session-Identifier) in der URL ist bedenklich!

Liebe Grüße
Tom S.

[pl]

Rechte solltest du nicht über die URL abbilden.

Und warum bitte nicht? Es ist wenig hilfreich wenn Du hier eine Empfehlung gibst ohne die weiter zu erläutern. MfG

[Rolf b]

Hallo pl,

weil es wenig hilfreich ist, in der URL "role=user" stehen zu haben und der User das mit "role=admin" übertippen kann.

Rechte eines Users müssen immer seinem serverseitigen Benutzerprofil basieren, das ausgehend von der Session-ID gefunden wird. Entweder ist er ausgeloggt, dann hat er Gast-Rechte, oder er ist eingeloggt, dann steht die User-ID in der Sessiondatei und basierend darauf wird die Rechtemenge bestimmt. Wenn das aufwändiger ist, kann man das Ergebnis in der Session-Datei cachen. Aber niemals dort, wo der User mit bösen Patschefingern hingreifen kann. Nicht in der URL. Nicht in HTML-Elementen. Nicht in der Keksdose. Nicht im Local Storage. Nur auf dem Server.

Ich frag mich aber gerade, was in diesem Fall passiert: Wenn ich eine böse Seite example.evil habe, die beim Aufruf den referer example.com bekommt, und dann ein HTML liefert, das in einem Frame example.com referenziert - dann würden die Aufrufe aus dem Frame doch auf die Keksdose von example.com zugreifen und die Session ID mitliefern. D.h. wenn example.com so gebaut ist, dass GET Requests mehr tun als nur Daten zu lesen, könnte example.evil mittels Referer Schaden anrichten. Oder?

Rolf

[1unitedpower]

Ich frag mich aber gerade, was in diesem Fall passiert: Wenn ich eine böse Seite example.evil habe, die beim Aufruf den referer example.com bekommt, und dann ein HTML liefert, das in einem Frame example.com referenziert - dann würden die Aufrufe aus dem Frame doch auf die Keksdose von example.com zugreifen und die Session ID mitliefern. D.h. wenn example.com so gebaut ist, dass GET Requests mehr tun als nur Daten zu lesen, könnte example.evil mittels Referer Schaden anrichten. Oder?

Ja, dabei ist der Referer nicht mal notwendig. Man nennt so einen Angriff Cross-Site Request Forgery, viele moderne Frameworks schützen auch automatisch davor, aber das sollte man im Zweifelsfall besser recherchieren und ggf. nachrüsten.

[pl]

Eine Berechtigung wird im URL sichtbar wenn ein autorisierter Benutzer z.B. mit edit=123 in den Bearbeitunsmodus wechselt oder mit delete=123 einen Löschvorgang tätigt.

[Tabellenkalk]

Hallo,

Eine Berechtigung wird im URL sichtbar wenn ein autorisierter Benutzer z.B. mit edit=123 in den Bearbeitunsmodus wechselt oder mit delete=123 einen Löschvorgang tätigt.

Für sieht das nicht nach Berechtigung aus, sondern nach Funktionsaufruf. Der Server muss dann prüfen, ob für diesen Funktionsaufruf die Berechtigung vorliegt.

Gruß
Kalk

[TS]

Hello,

... und da damit eine transiente Ressource bezeichnet wird, gehören die Daten nicht in eine URi. URis können üblicherweise als Link abgespeichert und auch weitergegeben werden. Aber warum soll ich einen Hinweis auf eine transiente Ressource abspeicherbar machen? Die ist doch beim nächsten Aufruf nicht mehr da!

Anders sieht das nach dieser Philosophie mit Links (URis) auf persistente Daten aus. Die sind durchaus sinnvoll :-)

Liebe Grüße
Tom S.

[pl]

Alles was vom Besucher/Benutzer verändert werden soll und darf, musst Du zwangsläufig auf Parametern abbilden. Die Alternative heißt Content Negotiation und speziell, was die Sprache betrifft Language Negotiation.

Beispiele Content und Language Negotiation:

URL /man.html ermöglicht je nach angemeldeten Benutzer bzw. Gruppe das Erstellen, Bearbeiten, Ändern und Löschen von Inhalten, also je nachdem wer sich da angemeldet hat, sind die Inhalte der Seite unterschiedlich.

URL /index.html ist enteder Englisch oder Deutsch je nachdem, welchen Accept Language Header der Browse sendet.

MfG

[TS]

Hello,

Alles was vom Besucher/Benutzer verändert werden soll und darf, musst Du zwangsläufig auf Parametern abbilden. Die Alternative heißt Content Negotiation und speziell, was die Sprache betrifft Language Negotiation.

Das ist zu diffus formuliert!

Alles was von jedem x-beliebigen unangemeldeten Besucher/Benutzer verändert werden darf, kann man in der URL abbilden, aber nur dann, wenn die so entstehende URL nachhaltig (persistent) ist. Ressourcen, die transient sind, sollten immer inerhalb des Requests, am besten im Request-Body, bzw. über das Session-Token auf dem Server in der Sessiondatei signiert werden.

So harmoniert das auch noch mit Referrern und SNI!

Liebe Grüße
Tom S.

[pl]

Alles was von jedem x-beliebigen unangemeldeten Besucher/Benutzer verändert werden darf, kann man in der URL abbilden,

Ich schrieb aber dass man das in Parametern abbildet. Also bitte richtig lesen und ggf, auch mal darüber nachdenken. Parameter sind nämlich nicht nur auf den URL beschränkt!

MfG