Session-Nutzung möglich? (Allgemeines zu Perl)

[thread]17198[/thread]

Session-Nutzung möglich?

Tags: perl5 session Ähnliche Threads

Leser: 26

Articles: hide open all | hide show old branches

+22 replies
Gast panni

2012-02-27 12:39

Hallo!

Ich habe mein Projekt "HandyApp <-> mein Perlprogramm als Schnittstelle <-> Perl-Hauptprogramm" so gut wie fertiggestellt.

Mir fehlt noch ein Punkt, wo ich keinen konkreten Ansatz finde.

Hintergrund ist, dass Aktionen durchgeführt werden können, bei denen der Nutzer nicht angemeldet sein muß, aber auch welche, wo zwingend eine Anmeldung des Nutzers mit seinen Benutzerdaten stattgefunden haben muß.

Es gibt eine Schnittstelle, über der sich der Nutzern authentisieren kann. Die App schickt beim Aufruf dieser den Benutzernamen und das Passwort.

Wenn die Daten korrekt sind, ist der Nutzer eingeloggt und bekommt einen Hashwert, den ich an die App schicke.

Im weiteren Verlauf schickt mir die App nur noch diesen Hash und eine Benutzer-ID mit, damit Benutzername und Passwort nicht jedes mal wieder übertragen werden müssen.

Wo mir jetzt der Ansatz fehlt, ist, wie ich jetzt das Wertepaar "UserId - UserHash" abspeichern kann.

Das ganze ist auf meiner Seite ja keine Browseranwendung, kann ich denn da trotzdem ein Perl-Sessionmanagement nutzen?

Oder muß ich mir einen anderen Weg ausdenken, wie ich das Wertepaar ablege und wie ich auf diese Ablage Zugriff nehmen kann, damit ich bei jedem Request prüfen kann, ob der Nutzer, der grade die Anfrage macht, auch ein korrekt eingeloggter Nutzer ist? Z.b. in eine Datenbank oder in eine Textdatei.

Vielen Dank und allen eine schöne Woche!
Last edited: 2012-02-27 12:43:10 +0100 (CET)
- +21 replies
- rosti
  
  2012-02-27 14:50
  
  User since
  2011-03-19
  3194 Artikel
  BenutzerIn
  
  Was Du brauchst ist zunächst eine bestehende Session mit Session-ID (SID). Diese wird zwischen Server und UserAgent (UA) ausgehandelt und hat mit dem Login ersteinmal nichts zu tun. Das Aushandeln der SID geht im einfachsten Fall über einen Cookie, hier die Schritte:
  
  - serverseitig wird geprüft, ob der UA die SID im Cookie schickt, wenn ja, wird diese genommen, sofern sie den Anforderungen genügt; eine Anforderung wäre z.b. 32 ASCII-Zeichen \w
  - schickt der UA keine SID, wird eine eindeutige SID erzeugt, z.B. mit Digest::MD5. Den Fall merken für später.
  - wenn serverseitig der Response-Header erzeugt wird, wird der Cookie mit der SID in einem der Header gesendet, dies kann entfallen, wenn es schon eine SID gibt (Merker von weiter oben).
  
  Damit ist die Voraussetzung für den Login gegeben: eine Synchrone SID, die für eine Browsersitzung gültig ist.
  
  Login: Die SID wird dem angemeldeten User zugeordnet und in einer Login-Tabelle gespeichert mit der SID als Key.
  
  Das ist Alles.
  
  Deine Frage: Keine Browser-Anwendung? Wenn ein Cookie im Spiel ist, brauchst Du einen UA, den kannst Du auch mit Perl nachbilden, da gibts Module.
  - +20 replies
  - panni
    
    2012-02-27 15:52
    
    User since
    2012-02-15
    23 Artikel
    BenutzerIn
    
    Hmmmmm :)
    
    Danke für die Info.
    
    Was ich nicht weiß, ob eine Handy-App überhaupt Cookies generiert und diese sendet. Deshalb soll als eine Art SessionId ein "userHash" geschickt werden.
    
    Was ich brauche, ist ein Sessionmanagment, was allein bei mir auf dem Server läuft und unabhängig vom Client ist. In die zu erzeugende Session möchte ich einfach die "userId" und den "userHash" reinwerfen und dann später nachschauen, ob es eine Session gibt, die den entsprechenden userHash enthält.
    
    Habe mich mit CGI::SESSION beschäftigt, da kann ich auch eine Session erzeugen und mit Werten füllen, aber beim nächsten Aufruf des Skriptes ist die Session weg bzw. meine zugefügten Werte nicht mehr existent *grübel*
    
    Was ich nciht weiss ist, ob das, was ich machen möchte, technisch überhaupt geht.
    - +19 replies
    - rosti
      
      2012-02-27 17:03
      
      User since
      2011-03-19
      3194 Artikel
      BenutzerIn
      
      Für Dich: http://rolfrost.de/cgi-bin/keks.cgi
      
      Damit kannst Du testen, ob der UA einen Cookie sendet.
      
      Wenn er das tut, siehst Du die SID immer mit dem gleichen Wert bei jedem Request, es sei denn, der UA schickt jedesmal eine andere SID.
      
      Wenn der UA keinen Cookie sendet, siehst Du die SID und den Hinweis, dass der UA keinen Cookie gesendet hat.
      
      Bitte teste das mal.
      Last edited: 2012-02-27 17:06:23 +0100 (CET)
      - +18 replies
      - panni
        
        2012-03-14 09:43
        
        User since
        2012-02-15
        23 Artikel
        BenutzerIn
        
        Hi!
        
        Ich möchte den Thread doch noch mal weiterführen.
        
        Aktuell versuche ich das Problem so zu lösen:
        - Nutzer loggt sich ein
        
        - ich erzeuge eine Session
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8
        
        sub createSession{ my ($userId) = @_; $appSession = CGI::Session->new(); $appSession->param(-name=>'userId', -value=>$userId); $appSession->param(-name=>'userHash', -value=>$appSession->id()); $appSession->expire("userId", &getSessionExpireTime); return $appSession->id(); }
        
        - wenn der Nutzer wieder auf die Seite kommt und die SessionId mitschickt, lade ich die Session so
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        sub checkSessionId { my ($userId, $sessionId) = @_; $appSession = CGI::Session->load($sessionId) or &errHandler::error(CGI::Session->errstr()); if ($appSession && ($userId == $appSession->param('userId'))) {return 1} return 0; }
        
        Dies klappt auch und ich habe mir keine weiteren Sorgen gemacht. Ich gehe davon aus, dass auf dem Server alle erzeugten Session gehalten werden und wenn dass ich per
        
        Code (perl): (dl )
        
        CGI::Session->load($sessionId)
        
        die Session mit einer bestimmten $sessionId laden und dann auf die in der Session zusätzlich gespeicherten Werte (hier $userId) zugreifen kann.
        
        Wie gesagt, klappt. Was aber nicht klappt und das macht mich unsicher, ob das ganze Modell nicht doch falsch ist, ist folgendes:
        wenn ich mir die $sessionId und $userId eines anderen Nutzers geben lasse, liefert die Funktion "checkSessionId" eine "0" zurück. Lasse ich mir die Werte ausgeben, so sehe ich, dass $appSession defined ist, aber $appSession->param('userId') leer ist.
        Nur damit steht bzw. eher fällt die ganze Sache.
        
        Aber eigentlich müsste es mir doch möglich sein, eine beliebige Session zu laden, wenn ich denn die zugehörige SessionId kenne, oder verstehe ich da etwas falsch?
        
        Viele Grüße und vielen Dank,
        panni
        Last edited: 2012-03-14 14:13:13 +0100 (CET)
        
        GwenDragon
        
        2012-03-14 11:51
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        1. mit Mothode is_empty geprüft, ob die Session leer ist?
        2. Session abgelaufen? Mothode is_expired
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +16 replies
        
        rosti
        
        2012-03-14 19:18
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        CGI::Session empfehle ich nicht, es macht die Sache unnötig kompliziert und ist umständlich zu handhaben. Beim Aufbau eines Login-Systems ist es einfacher, auf eine bestehende Session (Session-ID, SID) zuzugreifen, als eine Session erst dann zu erzeugen, wenn ein erfolgreicher Login vorliegt. Erst bei Letzterem wird serverseitig gespeichert mit der eindeutigen SID als Schlüssel.
        
        Das Aushandeln der SID jedoch, kann unabhängig vom Login erfolgen, wie das geht, habe ich weiter oben beschrieben und zum Verständnis poste ich mal das kleine Script, was ich ebenfalls weiter oben mal verlinkt habe.
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
        
        #!/usr/bin/perl use strict; use warnings; use CGI; use CGI::Cookie; use Digest::MD5 qw(md5_hex); # ein paar Variablen my $cookiename = 'SCHERZKEKS'; my %cookies = fetch CGI::Cookie; my $sid = undef; my $nocookie = undef; # nehme die SID aus dem gesendeten Cookie if(defined $cookies{$cookiename}){ $sid = $cookies{$cookiename}->value; # hier sollte noch geprüft werden, ob die SID # den Anforderungen genügt } else{ # erzeuge eine neue SID $sid = _makeSID(); $nocookie = "Kein Cookie vom UA bekommen\n"; } # Response if(defined $nocookie){ my $cookie = new CGI::Cookie( -name => $cookiename, -value => $sid, -path => '/', ); print "Set-Cookie: $cookie\n" ; } print "Content-Type: text/plain\n\n"; print "SID: $sid\n"; print $nocookie if $nocookie; exit; ########################################################################### # SessionID erzeugen sub _makeSID{ my @chars = ('A' .. 'Z', 'a' .. 'z', 0 .. 9, '+', '-'); my $len = scalar @chars; my $id .= time(); $id .= $$; for(my $i = 0; $i < $len; $i++){ $id .= $chars[int(rand($len))]; } $id = substr($id, 0, $len); $id = md5_hex($id); return $id; }
        
        Zu sehen ist, dass der Cookie-Header nur dann gesendet wird, wenn der Merker $nocookie gesetzt wurde. Selbst auf diese Kontrolle kannst Du verzichten, indem Du den Cookie-Header einfach immer sendest.
        
        Auf diese Art und Weise lässt sich eine Session viel einfacher integrieren, als mit CGI::Session, es steht eine $sid zur Verfügung, damit wird ein erfolgreicher Login gespeichert und bei nachfolgenden Requests anhand der Login-Tabelle geprüft, ob der Requester autorisiert ist.
        
        Login ist: Authentifizierung
        Login-Tabelle: Hier drin ist die Autorisierung hinterlegt, z.B. die Gruppenzugehörigkeit.
        
        Authentifizierung und Autorisierung sind zwei verschiedene Dinge.
        
        Session-Expires: Ein Session-Cookie hat keinen solchen Parameter. Der Browser löscht den Cookie beim Beenden der Sitzung, fertig.
        
        Login-Expires: Kann festgelegt werden, ist in der Login-Tabelle hinterlegt und sollte auch festgelegt sein für den Cleanup-Prozess.
        
        Das sind die Sachen, auf die es ankommt.
        
        Viel Erfolg!
        Rosti
        
        +15 replies
        
        GwenDragon
        
        2012-03-15 11:27
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Nette Lösung, nur unvollständig. Ohne Cookie keine Sessions möglich.
        Dein Beispiel führt ja den SessionId nicht als Parameter in der Url mit.
        Last edited: 2012-03-15 11:29:13 +0100 (CET)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +5 replies
        
        bianca
        
        2012-03-15 12:22
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        2012-03-15T10:27:17 GwenDragon
        SessionId nicht als Parameter in der Url mit.
        
        Welchen URL meinst du?
        10 print "Hallo"
        20 goto 10
        
        +4 replies
        
        GwenDragon
        
        2012-03-15 12:34
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Aus dem HTTP-Request zwischen Perl-Anwendung und App.
        
        Aber vielleicht kommunizieren die ja ganz anders.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +3 replies
        
        bianca
        
        2012-03-15 17:39
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        Für diese Kommunikation hat er doch garkein Beispiel gezeigt. Wie kann bei etwas was fehlen, was nicht da ist?
        10 print "Hallo"
        20 goto 10
        
        +2 replies
        
        GwenDragon
        
        2012-03-15 17:46
        
        User since
        2005-01-17
        14533 Artikel
        Admin1
        
        Ich weiß nicht, was du meinst? Die Anwendung kommuniziert doch über HTTP-Protokoll oder was denkst du? Werden Cookies nicht über HTTP versandt? Siehst du das anders?
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        bianca
        
        2012-03-15 17:58
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        Sehe ich genauso. Aber du reklamierst, dass im URL die SessionID fehlt. In welchem URL denn?
        Für die Kommunikation zum Script hin hat er doch garkein Beispiel geliefert. Oder sehe ich es nicht?
        
        2012-03-15T10:27:17 GwenDragon
        Dein Beispiel führt ja den SessionId nicht als Parameter in der Url mit.
        
        10 print "Hallo"
        20 goto 10
        
        +9 replies
        
        rosti
        
        2012-03-17 09:48
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Richtig: Ohne Cookie keine Session. HTTP-Cookies, von Netscape entwickelt, speichert der UserAgent (UA, Browser) lokal. Auf dieser lokalen, also clientseitigen Speicherung basiert mein Aufbau der Session und ist aus diesem Grund so einfach umzusetzen sowie integrierbar.
        
        Sicher gibt es außer dem HTTP-Header auch die Möglichkeit, eine SID im Body (POST) zu übertragen (bei GET um URL), jedoch geht in diesem Fall die Session verloren sobald der Besucher die Seite verlässt, was mit der Verwendung eines Cookie nicht der Fall ist. Darüber hinaus erfordert der Aufbau einer CookieLess Session den Eingriff in den Darstellungs-Layer (HTML) sowie parametrisierte URLs, die nicht ge-cached werden dürfen.
        
        Euch allen ein schönes Wochenende,
        Rosti
        
        +8 replies
        
        bianca
        
        2012-03-18 05:01
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        Habe dazu mal eine Frage: Wie löst du das, wenn ein Benutzer sich zweimal anmelden darf und will? Dann übermittelt das Cookie ja zwei Sessions und das Programm weiß nicht, in welcher der User gerade geklickt hat.
        Deshalb übergebe ich meistens auch noch per Post die Session.
        Gibt es da schönere Lösungen?
        10 print "Hallo"
        20 goto 10
        
        +7 replies
        
        rosti
        
        2012-03-18 09:19
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2012-03-18T04:01:55 bianca
        Habe dazu mal eine Frage: Wie löst du das, wenn ein Benutzer sich zweimal anmelden darf und will? Dann übermittelt das Cookie ja zwei Sessions und das Programm weiß nicht, in welcher der User gerade geklickt hat.
        Deshalb übergebe ich meistens auch noch per Post die Session.
        Gibt es da schönere Lösungen?
        
        Die Session ist unabhängig von der Anmeldung. Bei mehrmaliger Anmeldung bleibt die Session-ID (SID) dieselbe. Lediglich der Zeitstempel in der serverseitigen Logintabelle wird überschrieben. Meine Login-Tabelle speichert Objekte mit folgender Struktur:
        
        Code (perl): (dl )
        
        1 2 3 4 5
        
        SID => { # Session-ID, Schlüssel für den Login-Eintrag user => '', # Benutzername level => '', # Benutzergruppe, bei mir ein numerischer wert ts => '', # Zeitstempel }
        
        Der Zeitstempel ermöglicht die Bereinigung der LoginTable im Cleanup (DESTROY) und ist gleichzeitig die Verfallszeit eines 'Login'. Die Prüfung auf ein gültiges Login beschränkt sich somit darauf, über die SID einfach nur die Benutzergruppe abzufragen.
        
        Der Anmeldeprozess greift zum Prüfen der Credentials in eine weitere Tabelle, in welcher Benutzername, Passwort (Apache-MD5) und Gruppenzugehörigkeit hinterlegt sind.
        
        +6 replies
        
        bianca
        
        2012-03-18 09:30
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        Bei meiner Frage hatte ich vergessen zu sagen, dass ein und derselbe Benutzer sich zweimal anmelden darf und in beiden Anmeldungen unterschiedliche Berechtigungen hat. Er hat also zwei verschiedene ID's. Wie löst du das dann?
        10 print "Hallo"
        20 goto 10
        
        +5 replies
        
        rosti
        
        2012-03-18 09:43
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2012-03-18T08:30:13 bianca
        Bei meiner Frage hatte ich vergessen zu sagen, dass ein und derselbe Benutzer sich zweimal anmelden darf und in beiden Anmeldungen unterschiedliche Berechtigungen hat. Er hat also zwei verschiedene ID's. Wie löst du das dann?
        
        Meine Benutzername sind eindeutig, ein Benutzer kann jedoch mehreren Gruppen (Levels) angehören. Vor dem Auslieferen eines Response-Objekts wird einfach nur geprüft, ob es in der Login-Table einen Eintrag mit dem für die Ressource erforderlichen Level gibt.
        
        +4 replies
        
        bianca
        
        2012-03-18 10:53
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        Die Frage bezog sich darauf, wie deine Scripte unterscheiden, welcher Benutzer da jetzt gerade kommt.
        Wenn dieselbe Person unter mehreren Benutzern angemeldet ist liefert doch das Cookie alle Sessions. Wie unterscheidet das Script das?
        10 print "Hallo"
        20 goto 10
        
        +2 replies
        
        topeg
        
        2012-03-18 11:38
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        In solchen Fällen kommt man ohne Marker in der URL nicht klar.
        Ich habe das gelöst indem ich die URL um eine eindeutige ID ergänzt habe /pfad/zum/script.pl/<id>/seite und das cookie auf /pfad/zum/script.pl/<id> beschränkte. Damit wird immer nur das cookie geliefert, welches gerade aktiv ist.
        
        bianca
        
        2012-03-18 17:55
        
        User since
        2009-09-13
        6977 Artikel
        BenutzerIn
        
        Ja, danke, das war die Antwort auf meine Frage. Ich hatte gedacht, es gibt einen eleganteren - für den Benutzer nicht sichtbaren - Weg dafür.
        10 print "Hallo"
        20 goto 10
        
        rosti
        
        2012-03-18 11:47
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        2012-03-18T09:53:56 bianca
        Die Frage bezog sich darauf, wie deine Scripte unterscheiden, welcher Benutzer da jetzt gerade kommt.
        Wenn dieselbe Person unter mehreren Benutzern angemeldet ist liefert doch das Cookie alle Sessions. Wie unterscheidet das Script das?
        
        Es gibt mehrere Sessions aber wenn ein Response-Objekt (RO) erstellt wird, gibt es nur eine einzige und eindeutige SID, diese wird dem RO zugeordnet.
        
        Das Script unterscheidet nicht etwa nach Benutzer, sondern nach SID. Ein Request liefert _eine_ SID und kann auch nur eine SID als Cookie-Value im HTTP-Header mitgeben.
        
        Des Weiteren liegt von einem Benutzer nur eine Anmeldung vor, nicht mehrere. Diese eine Anmeldung ist der SID zugeordnet. Meldet sich ein Benutzer mehrmals an (aufeinanderfolgende Logins in einer Browsersitzung), bleibt die SID unverändert, es sei denn, er löscht den Cookie oder startet den Browser neu und bekommt somit eine neue SID zugewiesen.
        
        In letzterem Fall gibt es zwar mehrere SIDs zu einem Benutzer in der LoginTable, die Resssource wird jedoch nur dann ausgeliefert, wenn es der SID im Request entsprechend einen Eintrag in der LoginTable gibt mit dem für die Response erforderlichen Level (Gruppe).

View all threads created 2012-02-27 12:39.