>Da wo die 3 x sind schriebst Du Dein Passwort hin und legst Dir>die Verknüpfung auf den Desktop.>>Und schon bist Du jedesmal direkt eingelogt.
Könnte man hier nicht auch so etwas einrichten?
Ein sehr hilfreiches Feature, wie ich finde. Ein einloggen ohne Cookies
würde auch dazu beitragen, dass weniger Unfug mit fremden Nick's
getrieben wird.
Ggf. kann man ja noch einen Accounttyp einrichten, der nur eine
Namensreservierung ist und keine weitere Funktionalitäten bietet. Bzw.
nur einen Account für alles, der sich aber entsprechend einstellen
lässt.
Was meint ihr dazu?
Sebastian schrieb:> Ein sehr hilfreiches Feature, wie ich finde.
Ich nicht. Zum einen kann jeder in deiner Chronik dein Passwort im
Klartext sehen, zum anderen müssen Benutzername und Passwort bei jedem
Seitenaufruf erneut übergeben werden. Jeder, der also die URL sieht kann
sich auch einloggen. Wer die URL nur kurz kopiert, um sie irgendwo zu
teilen, teilt möglicherweise auch gleich seine Benutzerdaten mit.
Ich sehe auch kein Problem mit Cookies. Tracking Cookies kann man recht
zuverlässig blockieren. Session Cookies sorgen dagegen für erheblich
mehr Sicherheit, da eben nicht mehr bei jedem Seitenaufruf Benutzername
und Passwort mitgeschickt werden müssen.
Naja, man übergibt das Passwort doch ohne (gespeicherten) Cookie sowieso
bei Start der Sitzung (gut, nicht im Klartext). In der aktuellen Sitzung
bliebe der Login ja bestehen. Klar kann sich dann jeder, der diese URL
sieht einloggen. Aber ich klicke doch nur einmal beim Start der Sitzung
drauf und dann gibt's z.B. direkt eine Weiterleitung auf die Startseite
von µC.net. Dann brauche ich den Link mit Klartext Passwort nicht mehr.
Von daher finde ich das nicht so schlimm. Außerdem müsste es ja nicht
jeder nutzen. Und diejenigen, die es machen möchten, wissen von der
"Gefahr". Und was will schon jemand mit einem Benutzernamen aus diesem
Forum? Ein Passwort nur dafür ist natürlich selbstverständlich.
Mann kann es auch einfach so machen, dass wenn man über den Link
eingeloggt ist, einfach nur unter seinem Namen schreibt. Das
Benutzerkonto könnte dann weiterhin ein anderes Passwort haben. Dort
muss man sich dann richtig einloggen.
Wenn man soetwas schon umsetzt, dann wenigstens richtig. Eine URL kann
auch bei HTTP Benutzername & Passwort haben. Das Format wäre dann
https://username:password@domain/
Sebastian schrieb:> Vor allem kann man sich von all seinen Geräten einloggen, ohne das> Passwort immer raussuchen zu müssen. Man kann einfach den Link> abspeichern.
ich kann mich auch so überall einloggen ohne das Passwort rauszusuchen,
es ist im Passwortmanager gespeichert.
Wo ist da jetzt der unterschied?
Sebastian schrieb:> Das> Benutzerkonto könnte dann weiterhin ein anderes Passwort haben. Dort> muss man sich dann richtig einloggen.
Das klingt nach sehr viel Aufwand für einen relativ kleinen Nutzerkreis.
Sebastian schrieb:> In der aktuellen Sitzung> bliebe der Login ja bestehen.
Wie funktioniert das denn? Woher weiß der Server, dass ich auf den Link
geklickt habe und nun eingeloggt bin?
Daniel A. schrieb:> https://username:password@domain/
Bei der Lösung wird das Passwort auch bei jedem Aufruf mitgeschickt. Der
Unterschied ist nur, dass die meisten Browser die Benutzerdaten in der
URL verbergen. Mich würde allerdings wirklich mal interessieren, wie der
TO umsetzen will, dass das Passwort eben nicht jedes mal mitgeschickt
werden muss.
Hans schrieb:> Mich würde allerdings wirklich mal interessieren, wie der> TO umsetzen will, dass das Passwort eben nicht jedes mal mitgeschickt> werden muss.
Cookies, ist doch klar :D
Der Schrecken jedes Softwareentwicklers: "Kannst du nicht einen
komplexen Murks den niemand verwenden wird aus einem absurdem Grund
einbauen, auch wenn der jetzige sauber implementierte Mechanismus dafür
super funktioniert?" Schön, wenn man da einfach "Nö" sagen kann. Blöd,
wenn der Kunde König ist.
Hans schrieb:> Das wollte ich den TO eigentlich selbst herausfinden lassen.
So blöd bin ich auch nicht... In der Sitzung hätte ich Cookies, war
etwas unglücklich formuliert.
Es ging mir darum, das manuelle einloggen einzusparen, wenn ich meine
Cookies nach jeder Sitzung lösche (V-Maschine)...
Und PW-Manager sind mal außen vor. Mein Handy z.B. könnte das auch
nicht, aber einen Link speichern schon.
Sebastian schrieb:> Es ging mir darum, das manuelle einloggen einzusparen, wenn ich meine> Cookies nach jeder Sitzung lösche (V-Maschine)...
wo kommt den dann der link her?
>> Und PW-Manager sind mal außen vor. Mein Handy z.B. könnte das auch> nicht, aber einen Link speichern schon.
was für ein Handy kann Lesezeichen verwalten aber weder cookies halten
noch Passwörter speichern?
javascript:void((function(){login("Benutzername hier einsetzen","Passwort hier einsetzen");functionlogin(username,password){varf=document.createElement("iframe");f.onload=function(){varform=f.contentDocument.querySelector("form");form.name.value=username;form.password.value=password;f.onload=function(){location.reload();};form.submit.click();};f.style.visibility="hidden";f.src="https://www.mikrocontroller.net/user/login";document.body.appendChild(f);}})());
Sebastian schrieb:> So blöd bin ich auch nicht... In der Sitzung hätte ich Cookies, war> etwas unglücklich formuliert.
Dann ist dein konkretes Problem also Login per HTTP GET anstatt per
POST. Wie oben beschrieben kann man das allerdings relativ leicht mit
einem Javascript erreichen.
Hans schrieb:> Ich nicht. Zum einen kann jeder in deiner Chronik dein Passwort im> Klartext sehen,
Das ist wahr, aber natürlich nur dann ein Problem, wenn jemand an die
Chronik oder den Desktop-Link kommen kann -- und die meisten Menschen
hätten in so einem Fall vermutlich ganz andere Probleme als dieses.
> zum anderen müssen Benutzername und Passwort bei jedem> Seitenaufruf erneut übergeben werden. Jeder, der also die URL sieht kann> sich auch einloggen. Wer die URL nur kurz kopiert, um sie irgendwo zu> teilen, teilt möglicherweise auch gleich seine Benutzerdaten mit.
Nein, nicht unbedingt. Nach dem Login kann ein Session Cookie gesetzt
und dann auf eine Seite redirected werden, deren URL keine Credentials
mehr enthält.
> Ich sehe auch kein Problem mit Cookies. Tracking Cookies kann man recht> zuverlässig blockieren. Session Cookies sorgen dagegen für erheblich> mehr Sicherheit, da eben nicht mehr bei jedem Seitenaufruf Benutzername> und Passwort mitgeschickt werden müssen.
Wenn ich den TO richtig verstanden habe, ging es ihm nicht darum,
Cookies komplett zu vermeiden, sondern nur darum, sich ohne Cookie mit
einem Klick anmelden zu können. Im Übrigen hast Du bei Cookies ein
ähnliches Problem, wie Du es oben bei der Chronik (oder, das habe ich
hinzugefügt, dem Link auf dem Desktop) hast: wenn ein Angreifer an Deine
Chronik kommen kann, dann hat er auch Zugang zu Deinen Cookies.
