Erik Tews wrote:
> > - Paßwörter werden für jede Seite als Quasi-Klartext übertragen
>
> Könnte man durch nen SSL-Server verhindern
Ah, stimmt. Hab ich übersehen. Der stände in diesem Fall sogar auch
zur Verfügung.
> Noch nen Problem könnte das ausloggen sein. Ich bin mir nicht ganz
> sicher, aber afaik gibt es da keine Möglichkeit meinem Browser zu sagen,
> dass ich mich jetzt neu einloggen will, mit nem anderen Benutzernamen.
Iiieks, stimmt. Das spricht für Cookies (oder Session-ID's, die auch
nur Cookies mit potthäßlichem Kleid sind).
> Und natürlich ist das mehr Aufwand beim Einrichten. Wenn ich jetzt z. B.
> gezwungen bin, die Seite bei irgend nem komerziellen Webhoster
> aufzuspielen, dann kann ich halt nicht einfach das passende Auth-Modul
> für Postgresql einspielen.
Ok, aber .htaccess/.htpasswd stellen auch kommerzielle Webhoster
meistens zur Verfügung, oder? Das Programm ltp könnte problemlos eine
.htaccess-Datei generieren, die per cron in das Verzeichnis gelegt
wird, o.ä.
> > 2. Authentifizierung per PHP und Form
> >
> > + Wir können beim Einloggen ein Cookie erzeugen, mit dem man sich
> > für weitere Seiten authentifizieren muß.
>
> Schlecht, lieber ne Art von Session-ID, die wir dann an jeden Link
> dranhängen, so in der Art von edit.php3?id=asdfaer3qadsavdagewq, Cookies
> haben einige Leute deaktiviert.
NAK.
Session-ID's so wie Du sie haben möchtest, machen die URLs extrem
häßlich. Zudem sind statische Seiten mit Links in dem Bereich dann
nicht mehr möglich (das könnten z.B. Zugangsinformationen oder private
Telefonnummern sein, die nicht ganz öffentlich sein dürfen).
Oh, mit Cookies sind statische geschützt Seiten auch nicht mehr
möglich, da das Cookie überprüft werden müßte. Schade...
Dann eher die ID als Cookie übertragen mit der Möglichkeit von
login.php3 und logout.php3 zum Erstellen und Zerstören des Cookies.
Btw. auch wenn es jetzt so erscheinen sollte, ich bin generell kein
Freund von Cookies. Allerdings gibt es Applikationen, bei denen der
Einsatz von Cookies sinnvoll ist und das Arbeiten bequem und
transparent gestalten kann.
Cookies kann man auch wieder aktivieren für bestimmte Seiten. Ich
habe sie in manchen Browsern auch komplett deaktiviert. Wenn ich
allerdings eine Meldung bekomme, daß ich Cookies benötige und mir die
Verwendung logisch erscheint, kann ich sie für diese Site auch wieder
einschalten.
Ich bin im Gegensatz dazu *extrem* genervt und angepißt von Sites, die
mir ohne meinen Wunsch eine Session-ID in die URLs kleben und mich
damit tracebarer machen als ich es möchte. Cookies könnte ich einfach
ablehnen, diese ID's nicht.
> > - Wir müssen uns die Berechnung des Cookies gut überlegen und auch
> > dessen Zerstörung einplanen.
>
> Hm, ja, wie bereits gesagt, von Cookies würde ich absehen.
Session ID's, wie Du sie im Kopf hattest, haben noch einen weiteren
Nachteil: Die ID's erscheinen in den Proxy-Log von allen Proxies
unterwegs. Cookies würden 1:1 durchgereicht und nicht gespeichert
werden. Damit würden wir Misbrauch explizit fördern.
Zudem könnte man keine solche Seite mehr bookmarken, da irgendwann die
Session zuende ist bzw. sein sollte - oder ich habe das Konzept nicht
verstanden, was durchaus sein kann...
> > - Es muß geprüft werden, ob und wie man diesen Mechanismus
> > misbrauchen kann bzw. ob man sich darüber Zugriff "erschleichen"
> > kann.
>
> Zumindest wenn ich ne Session-ID habe, dann steht die afaik im Refer,
> wenn man von der Managementseite aus auf nen Link klickt. Das kann man
> aber über nen zwischenscript übergehen, also ich verlinke dann nicht auf
> www.debian.org sondern auf linkweiterleitung.php3?link=www.debian.org,
> und schon ist die Session-ID weg.
Wuuuaaargs... Das sieht ja übel aus...
> > Weiteres?
>
> Der Vorteil von der Auth per PHP ist, dass es out-of-the-box
> funktioniert, wir müssen also nicht erst den Webserver befummeln, und
> können auch alle Funktionalität im PHP-Code halten.
Im Prinzip eine gute Sache.
> Mein Vorschlag wäre die Personen-Tabelle so zu ändern dass wir noch 2
> weitere Felder bekommen, einmal eins für ne Session-ID, und dann noch
> mal ein weiteres für den Zeitpunkt des Einloggens. Wenn sich wer
> einloggen will, mach ich nen md5 über ne Kombination aus Uhrzeit, nen
> bisschen Urandom und noch was, und das Schreibe ich dann in das
> Session-ID Feld rein, und das ist dann auch das einzige, was der User
> dann jeder weiteren Seite übergeben muss. Und das funktioniert auch aus
> Erfahrung so weit ganz gut. Und diese Session-ID bleibt dann halt nur
> für sagen wir eine Stunde nach dem letzten Abruf einer Seite gültig.
Dann kann jeder andere, der ein Proxy-Log lesen kann, eine Stunde lang
unter einer anderen ID auf die Seite zugreifen. Das behagt mir gar
nicht.
Gruesse,
Joey
-- Experience is something you don't get until just after you need it.
This archive was generated by hypermail 2.1.3 : Sun Apr 28 2002 - 13:27:13 CEST