nicht angemeldet
passwortabfrage in javascript
hi,
ich benoetige für meine website eine simple passwortabfrage in javascript. ich dachte an ein feld und einen button, und wenn der button geklickt wird, soll er auf eine neue seite verweisen die aus 'mainpage'+ dem passwort zusammengesetzt ist. wenn das passwort dann falsch is kommt halt document not found.
nur leider haben meine bisherigen versuche meist ins nichts geführt, bzw. es passiert einfach nix.
gruß
_SiNnEr_
-
Hi,
ich benoetige für meine website eine simple passwortabfrage in javascript. ich dachte an ein feld und einen button, und wenn der button geklickt wird, soll er auf eine neue seite verweisen die aus 'mainpage'+ dem passwort zusammengesetzt ist. wenn das passwort dann falsch is kommt halt document not found.
nur leider haben meine bisherigen versuche meist ins nichts geführt, bzw. es passiert einfach nix.wie sehen denn Deine bisherigen Versuche aus?
Du solltest übrigens wissen, daß auch die ausgeklügeltste Passwortabfrage in JavaScript alles andere als sicher ist. Wenn ein Minimum an Sicherheit gewährleistet sein soll, solltest Du die Artikel über .htaccess unter http://www.teamone.de/selfaktuell/ beachten.
Cheatah
-
Hi Cheatah!
Die Methode mit dem Link auf eine Seite die so heitßt wie das Paßwort, ist meiner Meinung nach ziehmlich sicher. Denn ich denke nicht, daß du den Namen der Datei errätst (du könntest ja genausogut das Pwd eines "echten" login erraten).
Der einzige Nachteil ist halt, daß es nur mit eingeschaltetem JavaScript funktioniert.
grüße,
BRAND-
Hi,
Die Methode mit dem Link auf eine Seite die so heitßt wie das Paßwort, ist meiner Meinung nach ziehmlich sicher.
es ist auf jeden Fall die sicherste in JavaScript mögliche. Bedenke aber, daß die exakte URL anschließend in Histories und Referrer-Logs auftauchen kann und wird - und einige Clients liefern _sehr_ merkwürdige Referrer ab. Beispielsweise kann es vorkommen, daß wenn Du nach einer "geschützten" Seite meine URL eintippst, ich den Link in meinen Logfiles finde.
Der einzige Nachteil ist halt, daß es nur mit eingeschaltetem JavaScript funktioniert.
Nicht der einzige, aber der auf den ersten Blick gravierendste. Schlimmer ist aber, daß die Sicherheit bei näherer Betrachtung sich eben doch als nur scheinbar entpuppt.
Zusätzlicher Nachteil: Entweder schreibst Du für jeden Benutzer eine eigene Seite, oder jeder Benutzer hat das selbe Passwort. Verschiedene Passwörter für die selbe Seite gehen einfach nicht.
Noch ein Nachteil (Sicherheitsaspekt): Man kann problemlos Direktlinks zu der Seite ablegen.
Cheatah
-
Zusätzlicher Nachteil: Entweder schreibst Du für jeden Benutzer eine eigene Seite, oder jeder Benutzer hat das selbe Passwort. Verschiedene Passwörter für die selbe Seite gehen einfach nicht.
... außer man emuliert sie mit symbolic links auf dem (UNIX-) Webserver.
-
Hi,
Zusätzlicher Nachteil: Entweder schreibst Du für jeden Benutzer eine eigene Seite, oder jeder Benutzer hat das selbe Passwort. Verschiedene Passwörter für die selbe Seite gehen einfach nicht.
... außer man emuliert sie mit symbolic links auf dem (UNIX-) Webserver.
jupp. Ich zähle symbolic links aber auch zu Dateien; sie sind schließlich im Filesystem verankert.
Cheatah
-
Zusätzlicher Nachteil: Entweder schreibst Du für jeden Benutzer eine eigene Seite, oder jeder Benutzer hat das selbe Passwort. Verschiedene Passwörter für die selbe Seite gehen einfach nicht.
... außer man emuliert sie mit symbolic links auf dem (UNIX-) Webserver.
jupp. Ich zähle symbolic links aber auch zu Dateien; sie sind schließlich im Filesystem verankert."schreibst Du" klang nach n-facher Platzbelegung und n-facher Inhaltswartung, da wollte ich nur noch schnell anmerken ...
Außerdem: Für mich zählen links nicht zu den Dateien. (Verzeichnisse ja auch nicht. ;-)
(Du hättest mich heulen sehen sollen, als ich das Backup meines UNIX-Webservers per FTP auf meinen WinNT-Entwicklungsrechner duplizieren wollte: Bei *jedem* einzelnen symbolic link stürzte WS_FTP ab ... :-(-
Hi,
Außerdem: Für mich zählen links nicht zu den Dateien. (Verzeichnisse ja auch nicht. ;-)
ich könnte Dir ja jetzt etwas von WEB.DE erzählen, und wie die einzelnen Dokumente (Dateien) und Ebenen (Verzeichnisse) aus der Datenbank kommen, aber das laß ich dann doch lieber ;-)
(Du hättest mich heulen sehen sollen, als ich das Backup meines UNIX-Webservers per FTP auf meinen WinNT-Entwicklungsrechner duplizieren wollte: Bei *jedem* einzelnen symbolic link stürzte WS_FTP ab ... :-(
Ei hoppala... im per HTTP verfügbaren System? Vielleicht hättest Du lieber mod_rewrite nehmen sollen... :-)
Cheatah
-
(Du hättest mich heulen sehen sollen, als ich das Backup meines UNIX-Webservers per FTP auf meinen WinNT-Entwicklungsrechner duplizieren wollte: Bei *jedem* einzelnen symbolic link stürzte WS_FTP ab ... :-(
Ei hoppala... im per HTTP verfügbaren System? Vielleicht hättest Du lieber mod_rewrite nehmen sollen... :-)?!!? Kannitverstan.
Meine UNIX-Kiste (ex-Intranet-Webserver) existiert nicht mehr.
Auf einer anderen hatte ich das Sicherungsband eingelesen, aber nur in ein Verzeichnis, wo es eigentlich nicht hingehörte. Die Daten mußten also wieder weg.
Auf meinem PC habe ich einen Apache laufen, da konnte ich meinen Intranet-Server also "parken" (natürlich funktionierte von den shell-CGIs nichts mehr usw.).
Und dieses Parken habe ich dann via PC-FTP-Client gemacht, welcher leider symbolic links der UNIX-Kiste nicht versteht und während der Übertragung ständig abstürzte.
Was nützt mir dabei ein "mod_rewrite"???
-
-
-
-
-
-
-