Hallo miteinander, ich habe ein etwas ausgefallenes Problem und bin etwas ratlos. Ich habe ein online-Verwaltungssystem in PHP erstellt, bei dem sich die Benutzer ganz normal mit Accounts anmelden. Jetzt soll es eine bestimmte Station geben, von der aus eben ein ganz bestimmter Funktionsaccount automatisch drin ist. Die Zugangskontrolle ist in dem Fall dann einfach der Zugang zum Rechner, vor Ort soll es schnell gehen und sich die Leute nicht erst jeder einzeln anmelden müssen. Wie könnte man sowas mit PHP, JavaScript o.ä. realisieren? Da der Client ebenfalls von mir mitverwaltet wird und ausser Terminal für die Datenbank zu spielen keine weitere Funktion hat, darf es ruhig etwas spezielleres sein, bzw eine Methode, die eine bestimmte Konfiguration/Installation am Rechner voraussetzt. Würde mich über ein paar Anregungen sehr freuen. Gruß Jens
Jens Plappert schrieb: > Würde mich über ein paar Anregungen sehr freuen. Anmeldung über die .htaccess machen, dann einfach "Passwort merken" setzen. schon wird immer der Login Name mitgesendet. Oder noch etwas sicherer, Anmeldung über Client-Zertifikat.
Jens Plappert schrieb: > bei dem sich die > Benutzer ganz normal mit Accounts anmelden. > > Rechner, vor Ort soll es schnell gehen und sich die Leute nicht erst > jeder einzeln anmelden müssen. Und jeder, der an diesem Rechner sitzt, soll auf demselben Account rumaendern? wendelsberg
Jetzt Nicht schrieb: > Den Rechner kann durch die IP identifizieren. ja, wenn kein Internet dazwischen hängt.
>Und jeder, der an diesem Rechner sitzt, soll auf demselben Account
rumaendern?
Das kann schon Sinn machen wenn der account z.B. hauptsächlich
Informationen zu Verfügung stellen soll und daher nur Leserechte
benötigt.
viel Erfolg
Hauspapa
Es geht um eine Fahrtenverwaltung für einen Verein. Das ganze ist nur die elektronische Variante eines "Heftes", in das sich jeder einträgt. Von daher genügt ein gemeinsamer Account für den Rechner vor Ort. Die personalisierten Accounts können dann ihr eigenes Material usw Verwalten, was jetzt vom Vereinsheim aus nicht wirklich notwendig ist. Von daher passt das schon. Bisher könnte ja auch jeder in der Liste rumkritzeln. Bei dem begrenzten Benutzerkreis, bei dem auch jeder ein Eigeninteresse für ein funktionierendes System hat, schliesse ich jetzt mal Missbrauch aus (zumal der Account natürlich auch sehr eingeschränkt ist). Der Benutzer kann auch nichts groß Ändern oder manipulieren, nur Datensätze erstellen (also eigene aktuelle Sachen eintragen). Maximaler Fehlerfall wäre also "Spam". Da das ganze in einem Webhosting-Paket läuft (also kein selbstverwalteter Server), stell ich mir das mit den Zertifikaten schwierig vor. Wird .htaccess denn in den Browsern zuverlässig abgelegt und behalten? Ich wollte jetzt ungern Daten eines Accounts einfach so als Zettel dranpappen. Erkennung über IP geht leider nicht, da die Anwendung online läuft und der Rechner über eine normale Internetverbindung (sprich wechselnde IP) reingeht. Eine zuverlässige und sichere Methode die GUID oder MAC mit PHP/Javascript/CGI auszulesen gibt es meines Wissens nach nicht, oder irre ich mich da? Vielen Dank schonmal für die Antworten und Gruß Jens
Hi ich hab zwar absolut keine Ahnung von dem ganzen Browser- und Webzeug aber würde es nicht reichen sich einmal mit dem speziellen Account an dem Rechner einzuloggen und dann ein Cookie mit entsprechenden Informationen zu setzen? Matthias
Mir erscheint das halt als zu unsicher (unsicher im sinne von Betriebssicher). Sollte irgendwie mal das Cookie bzw die Session dazu ungültig werden, musste dich neu einloggen, das möchte ich nach Möglichkeit vermeiden.
Jens Plappert schrieb: > Ich wollte jetzt ungern Daten eines Accounts einfach so als Zettel > dranpappen. Jens Plappert schrieb: > Bisher könnte ja auch jeder in der Liste > rumkritzeln. Bei dem begrenzten Benutzerkreis, bei dem auch jeder ein > Eigeninteresse für ein funktionierendes System hat, schliesse ich jetzt > mal Missbrauch aus (zumal der Account natürlich auch sehr eingeschränkt > ist). Der Benutzer kann auch nichts groß Ändern oder manipulieren, nur > Datensätze erstellen (also eigene aktuelle Sachen eintragen). Jens Plappert schrieb: > Mir erscheint das halt als zu unsicher (unsicher im sinne von > Betriebssicher). > > Sollte irgendwie mal das Cookie bzw die Session dazu ungültig werden, > musste dich neu einloggen, das möchte ich nach Möglichkeit vermeiden. Das ist dann doch auch nicht so schlimm, da wird eben das Vereinsheim als Hochsicherheitszone deklariert und der Zettel mit dem Accountdaten kommt UNTER die Tastatur. ;-) wendelsberg
Ich rechne ja eigentlich nicht mit missbrauch, aber einen bekannten Funktionsaccount rückt man mal eben leichter raus, als "seinen eigenen". Ich spiel jetzt einfach mal mit htaccess rum und habe in dem Verzeichnis dann ein Script, dass mich automatisch am System anmeldet, bisher erscheint mir das am praktikabelsten.
Warum kompliziert wenn es einfach geht? Der Rechner im Vereinsheim ruft die Website mit einem speziellen GET oder besser POST Parameter auf welchen keiner kennt und der fix einprogrammiert gespeichert ist. In PHP wird GET/POST abgefragt und wenn der String passt dann der vereinsheimaccount eingeloggt (:
Markus H. schrieb: > Warum kompliziert wenn es einfach geht? > > Der Rechner im Vereinsheim ruft die Website mit einem speziellen GET > oder besser POST Parameter auf welchen keiner kennt und der fix > einprogrammiert gespeichert ist. > > In PHP wird GET/POST abgefragt und wenn der String passt dann der > vereinsheimaccount eingeloggt (: BITTE nicht. Sicherheit auf Basis "was keiner kennt" ist keine. Weil was keiner kennt, kennt am Ende jeder. Was Du hier willst kann so leider nicht umgesetzt werden, ausser Du bindest ActiveX oder Java mit ein (nicht Javascript. Java). Damit könnte man beispielsweise die CPUID auslesen, die den Rechner identifizieren würde. Was allerdings natürlich zu Problemen führen wird wenn der Rechner getauscht werden muss, auch klar. Mit "herkömmlichen" Scriptsprachen und anderen browserinternen Tools kommt man dort nicht hin, weil die aus ihre Sandbox nicht ausbrechen können (sollten... aber sich auf einen Exploit verlassen ist auch nicht wirklich 'ne Idee...). Die sinnvollste und einfachste Lösung scheint mir hier immer noch die mit dem Session Cookie zu sein, das eben nie abläuft und wo, wenn mal wirklich jemand die Cookies löschen sollte aus irgendeinem noch nicht ganz logischen Grund, die Credentials halt die "Berechtigten" gesagt bekommen, damit diese sich halt trotzdem einloggen können. Alles andere wird wahrscheinlich mehr Kopfschmerz verursachen als die Usability hergibt.
z.B. 1.Usergruppe bilden, die sich anmelden DARF? Damit könnte jedes Mitglied sein eigenes PW benutzen. 2.Oder lange laufendes, eigenes Client-Zertifikat erstellen? Es sollte dann in diesem einen PC bekannt sein. Vorteil ist: Es ist HW-unabhängig, falls PC mal defekt sein sollte.
gib dem rechner im vereinsheim dyndns und vergleiche dann ob die ip stimmt.
Hallo, die zuverlässigste Möglichkeit zur Identifikation des Clientrechners wäre eine Authentifizierung über TLS-Zertifikate. Das wäre zwar maximal sicher, aber nicht sonderlich trivial: der Rechner im Vereinsheim und der Server hätten dann eine gemeinsame CA, und wenn der Client ein von dieser CA beglaubigtes Zertifikat vorlegt, wird er automatisch authentifiziert und autorisiert. In diesem Fall stellt sich jedoch die Frage, wie das mit den externen Nutzer funktionieren könnte. Wenn bei den externen Nutzern ein Zertifikat installiert werden kann, wäre das zwar ideal, aber ziemlich aufwändig und bei manchen Clients eventuell auch gar nicht möglich (think firmeneigene Rechner oder Smartphones). Daher müßte der Server auf eine der üblichen Login-Methoden zurückgreifen, wenn der Client ein "fremdes" Zertifikat präsentiert, welches nicht von der gemeinsamen CA beglaubigt worden ist. Genau hier wird das Setup dann ziemlich kniffelig. Eine einfachere Möglichkeit wäre es, wenn der Vereinsheim-Client über ein VPN oder einen SSH-Tunnel auf den Server zugreift. Dann kommt der Client aus Sicht des Servers von einer definierten Adresse wie beispielsweise localhost (127.0.0.1), und kann darüber authentifiziert und autorisiert werden. Alle anderen Clients würden die externe IP-Adresse über HTTPS benutzen, müßten sich über HTTP-Basic-Auth oder die Applikation anmelden und authentifizieren. Dazu wäre aber ein VPN- oder ein SSH-Server nötig, den der Vereinsheim-Rechner zugreifen und den er ohne manuelle Eingriffe durch die Benutzer auf- und abbauen kann. Liebe Grüße, Karl
Heinz L. schrieb: > Was Du hier willst kann so leider nicht umgesetzt werden, ausser Du > bindest ActiveX oder Java mit ein (nicht Javascript. Java). Damit könnte > man beispielsweise die CPUID auslesen, die den Rechner identifizieren > würde. Was allerdings natürlich zu Problemen führen wird wenn der > Rechner getauscht werden muss, auch klar. > > Mit "herkömmlichen" Scriptsprachen und anderen browserinternen Tools > kommt man dort nicht hin, weil die aus ihre Sandbox nicht ausbrechen > können (sollten... aber sich auf einen Exploit verlassen ist auch nicht > wirklich 'ne Idee...). So stimmt das nicht ganz, der Suchbegriff lautet "device fingerprint" http://en.wikipedia.org/wiki/Device_fingerprint Ein Beispiel gibt es auf https://panopticlick.eff.org/index.php?action=log&js=yes Dabei werden Browser eigene Funktionen genutzt, um eine Kombination aus Sprache, installierten Fonts, Softwareversionen, installierten Plugins, ggf. Resultate aus verdecktem Zeichnen, etc. zu gewinnen. Das ist eine ziemlich einzigartige Kombination, die zwar einem gewissen Drift unterliegt, aber es erlaubt insbesondere häufig wiederkehrende Besucher der Webseite zu tracken (nicht zu sprechen von Cookies und ähnlichen aktiven Maßnahmen). Das taugt aber natürlich für das geschilderte Anwendungsszenario nur bedingt bis gar nicht.
oder auf dem Client ein eigenes Kleines Tool, das aus nicht mehr besteht, als einem, html-renderfenster. Da kann man den anzuzeigenden Link fest vorgeben und auch einen speziellen Identifikationsparameter (zB als Urlparameter) mitschicken. Ich hscätze mit QT ist sowas relativ schnell implementiert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.