[vz-dev] Zugang zum Frontend absichern

pe82 at gmx.de pe82 at gmx.de
Thu Jan 12 18:53:24 CET 2012


> pe82 at gmx.de, 2012-01-12 15:21:
> > Meine Absicht: Ich will mich am Server authentifizieren, sodass a)
> > niemand anderes Kanäle anlegen kann und b) niemand einen Nutzen von
> > meiner UUID hat. Aus Sicherheitsgründen erfolgt die Verbindung über
> > SSL.
> > 
> > Vorgehensweise: Der vhost domain.com:80 leitet weiter auf
> > domain.com:443 Der vhost domain.com:443 kümmert sich auch um die
> > Authentifizierung
> 
> Die Frage war ja, wie du sicherstellst, daß du nur von deinem eigenen
> Frontend deine Daten lesen kannst. Ich nehme mal an, du benutzt dafür
> domain.com:443 mit dem Umstand, daß der Browser automatisch die
> Anmeldedaten beim Zugriff auf domain.com:443/middleware/ mitschickt,
> wenn er sich bei domain.com:443/frontend/ angemeldet hat.
Genau :) bzw. Apache fragt über die normalen Authentifizierungsmechanismen nach dieser Authentifizierung.

> 
> > Eine mögliche Lösung: operation=whatever nur bei GET erlauben, da der
> > Parameter (soweit ichs überblicken kann) nur als Unterstützung beim
> > Testen gedacht ist sodass man über den Browser alle Befehle der API
> > ausnutzen kann.
> 
> Ist wohl so, aber ich bezweifle mal, daß das die richtige Lösung ist.
> Der nächste möchte vielleicht nur GET zulassen und läuft dann auf das
> selbe Problem.
Ja das stimmt. Ich will die Lösung auch nicht aufs Repository prügeln, sondern erstmal schauen obs nur für mich so geht und ob es einen Eintrag ins Wiki wert ist oder nicht. Die Frage nach Authentifizierung kommt ja schon häufiger.

> Aber du kannst doch in rewrite-rules auch auf den QUERY_STRING
> zugreifen. Damit könntest du auf operation= matchen und den Request
> ablehnen. Wobei, gerade bei POST kann man das auch im Request
> mitschicken, damit wäre also nichts gewonnen. Du könntest die Größe
> des
> request-body begrenzen, sowas wie BODY_SIZE gibt's wohl leider nicht,
> eine Alternative wäre LimitRequestBody 1 (0 ist unlimited) für den
> controller-vhost verhindern, das überhaupt (sinnvolle) POST-Daten
> übergeben werden (der e6-watchasync benutzt auch bei POST
> URL-Parameter). Ist aber schon etwas hacky das ganze...
QUERY_STRING war auch das Erste was ich versucht hab, aber das matcht leider nicht auf die POST-Parameter wie du schon schreibst.
Dein anderer Vorschlag hört sich auch interessant an. So müsste ich zumindest nichts im Quellcode umbauen.
Andererseits ist das noch hackiger als mein ursprünglicher Vorschlag, weil es ja schon nicht unwahrscheinlich ist dass ein Controller das Zeug zukünftig in POST-Variablen übergibt. Zumindest isses für die Funktion potentiell relevanter als der operation-Parameter.

Gruß,
Pepe


More information about the volkszaehler-dev mailing list