Announcement

Collapse
No announcement yet.

Kann man noch mit dem SessionD reden?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kann man noch mit dem SessionD reden?

    Hallo,

    beim OX5 konnte ich damals über Port 33333 mit dem SessionD sprechen und so z.B. den Benutzernamen zu einer Session herausfinden.

    Jetzt sind wir gerade im Update von OX5 auf OX6 und irgendwie hört der nicht mehr..

    Ich hatte dazu die "sessiond.properties" gefunden und mal versucht da ein paar Werte auf "true" zu setzen, jedoch brachte dies keine Hilfe.

    Funktioniert dieser Weg überhaupt noch, oder gibt es Alternativen?

    Was ich vordringlich benötige:

    - Aus dem schon bestehendem Sessioncookie (JSESSIONID/open-xchange-secret) den Benutzernamen herausfinden.


    Schonmal vielen Dank für eure Hilfe!
    Chris

  • #2
    Hallo Chris,

    das Verhalten wie bei OX5 ist in OX6 nicht mehr vorhanden, da sich konzeptionell sehr viel geändert hat. Wenn du ein Cookie und die Session hast, kannst du die HTTP API nutzen um über einen entsprechenden Call den Benutzernamen und vieles mehr abzufragen. Siehe: http://oxpedia.org/wiki/index.php?title=HTTP_API

    Gruß

    Comment


    • #3
      Hallo Martin,

      vielen Dank für deine Antwort.

      Ich habe es gefunden! Vielen Dank!!


      Beste Grüße!
      Last edited by Guest; 11-15-2010, 04:29 PM.

      Comment


      • #4
        Problem:

        Ich erhalte das:
        {"category":3,"error_params":[],"error":"Request to server was refused. Original client IP address changed. Please try again.","error_id":"130881951-519","code":"SES-0205"}

        Hätte ich mir denken können, dass so etwas geprüft wird
        Ist das jetzt ein Problem mit der Java-Session, oder OX intern?
        Und viel wichtiger: Kann ich diese Prüfung einfach abschalten??

        Comment


        • #5
          Hi,

          tatsächlich wird neben dem cookie und der session id auch die IP Adresse des Clients geprüft um beispielsweise cookie stealing etc. zu entschärfen. Dies kann man abschalten (sollte man aber nicht!) in der Datei /opt/open-xchange/etc/groupware/server.properties

          Code:
          # On session validation of every request the client IP address is compared with the client IP address used for the login request. If this
          # configuration parameter is set to "true" and the client IP addresses do not match the request will be denied and the denied request is
          # logged with level info. Setting this parameter to "false" will only log the different client IP addresses with debug level.
          #
          # WARNING! This should be only set to "false" if you know what you are doing and if all requests are secure - requests are always encrypted
          # by using HTTPS.
          com.openexchange.IPCheck=true
          Im Kommentar der Option steht eigentlich schon alles - man sollte es nur deaktivieren wenn wirklich nötig da es die passive Sicherheit fördert.

          Gruß

          Comment


          • #6
            Hi,

            super, vielen Dank. Es funktioniert jetzt alles so, wie ich es mir vorgestellt habe.

            Das Sicherheitsrisiko ist mir bewusst, jedoch akzeptabel, da Verbindungen aus dem WAN nur über SSL erfolgen können.


            Vielleicht fällt ja jemanden noch ein besserer Lösungsansatz ein, für das, was ich jetzt umgesetzt habe.

            Um dem User individuellen Inhalt ohne zusätzliche Authentifizierung zeigen zu können, muss ich wissen um welchen User es sich handelt.

            Da ich alle Cookies vom User z.B. in meinem PHP-Skript habe, starte ich jetzt einen Request auf den OX mit den "geklauten" Sessiondaten und finde so heraus, welcher User ich bin. Nachdem ich den Usernamen weiß, kann ich individuelle/geschützte Inhalte zeigen.

            Nochmal vielen Dank und beste Grüße

            Comment

            Working...
            X