Archive

Posts Tagged ‘Session’

Stumbling Stone: sessionScope is for everyone…

19/07/2012 2 comments

Today, I saw something surprising that I want to share with you.

sessionScope is for everyone… Many of us know that one should be careful with the sessionScope because the handling can be quite difficult if you don’t take care whether the sessionScope is deleted or renewd if you don’t need the value anymore. Maybe I will write another article about my favorite topic, because I made a lot of mistakes in my first XPages applications.

So, what do I mean with the heading? Imagine the following example:

User1 writes a value “test 1” in the sessionScope variable “test container”. We know that means that, as long as the user is logged in, he can access this value and no other user can access this variable with this value.

That’s not correct!

User2 can also access this value, under certain circumstances. It is not very likely to happen, but if User 1 and User2 use the same computer, they share their sessionScope.

The sessionScope is saved in a cookie. And as long as this cookie isn’t deleted, all users who use the computer will have the value of User1 in their sessionScope. Even if you logout, close the browser and reopen the browser. The cookie is still there, and so is the sessionScope value.

You can try it very easily:

<?xml version="1.0" encoding="UTF-8"?>
  <xp:view xmlns:xp="http://www.ibm.com/xsp/core">
    <xp:inputText id="inputText1"></xp:inputText>
    <xp:br/>
    <xp:button value="Label" id="button1">
      <xp:eventHandler event="onclick" submit="true"
        refreshMode="complete">
        <xp:this.action><![CDATA[#{javascript:
          synchronized(sessionScope) {
            sessionScope.put("test", getComponent("inputText1").value);
          }}]]>
      </xp:this.action>
    </xp:eventHandler>
  </xp:button>
  <xp:br/>
  <xp:text escape="true" id="computedField1">
    <xp:this.value><![CDATA[#{javascript:sessionScope.get("test")}]]></xp:this.value>
  </xp:text>
</xp:view>

Open this page as User1, set any value, close the browser and reopen it, login with User2 and open this page. You will see the old value from User1.
So, if anyone has an application which is used in public, or the users of the application could switch their computer, you should be very careful. It could lead to the strangest errors in your application, or cause some trouble because of data security/ data privacy. If you even think of the idea to control some access rights via sessionScope, or store a user related object in the sessionScope, you maybe should think of another solution.

Advertisements

XPages: Notes Objekte in Java Singleton Patterns

28/03/2012 3 comments

Ich hatte ja vor einer Weile in diesem Post am Ende von einem Problem berichtet, welches ich im XPages Forum gepostet habe.

Gestern habe ich mit Philippe Riand, dem Chef-Entwickler der XPages von IBM, über das Problem gesprochen. Hier ist die Erklärung:

Ich habe ja das NoteDatabase Objekt in der Klasseninstanz als Attribut gespeichert. D.h. dass bei jedem Request das gleiche Objekt verwendet wird, wie es ja auch bei einem Singleton Pattern sein soll.
Aber: Nach jedem Request wird ein NotesDatabase Objekt recycled, und zwar schon seit 8.5.1. Das hat einfach den Hintergrund, dass in dem NotesDatabase Objekt die Credentials des Users, der den Request abgeschickt hat, mitgespeichert werden. So würde, wenn User A die Funktion aufruft und die Klasse initialisiert, und dann User B die gleiche Funktion aufruft, die gleiche Instanz verwenden, in dem das NotesDatabase von User gespeichert ist. Würde somit die Funktion mit den Berechtigungen von User A aufrufen. Das darf natürlich nicht passieren. Daher wird, schon seit 8.5.1, ein NotesDatabase Objekt nach jedem Request recycled. Da das ganze in dem Singleton Pattern abläuft ist natürlich das Objekt noch da und nicht Null, hat aber keine Referenz mehr zur eigentlichen Datenbank und wirft somit den Fehler dass das Objekt removed oder recycled wurde.

Macht von dem Gesichtspunkt her natürlich auf jeden Fall Sinn, man muss es halt nur wissen.

Natürlich ist die Frage warum es dann bei mir unter 8.5.1 funktioniert hat. Die einzige Erklärung die wir finden konnten war, dass dies ein Bug unter 8.5.1 sein muss. Das sollte man denke ich auf jeden Fall mal bei sich in den Anwendungen überprüfen, da dies theoretisch ein ziemliches Sicherheitsrisiko sein kann.

Stattdessen sollte man, z.B. beim Aufruf der getInstance Methode die aktuelle Datenbank übergeben oder sich in der Java Klasse das Objekt direkt holen und jedes Mal neu setzen.

%d bloggers like this: