Unexpected behavior in _createSession

[atarkowska]

If username is equal live session uuid, it will join the session, rather then create new session for the given user.
It was noticed during the testing. Basically first connection was created by root, then root created the user with omename=root.sessionUuid. Then user was trying to create the new connection with its own client object. That scenario was not possible. Every time user were joining root session.

Is this expected behavior?

def _createSession (self, skipSUuid=False):
        """
        Creates a new session for the principal given in the constructor.
        Used during L{connect} method
        
        @param skipSUuid:   TODO: Never used (not specified in any calls from connect() either)
        @type skipSUuid:    Boolean
        """
        s = self.c.createSession(self._ic_props[omero.constants.USERNAME],
                                 self._ic_props[omero.constants.PASSWORD])
        self._sessionUuid = self.c.getSessionId()
        ss = self.c.sf.getSessionService()
        self._session = ss.getSession(self._sessionUuid)
        self._lastGroupId = None
        s.detachOnDestroy()
        self._was_join = False
        if self.group is not None:
            # try something that fails if the user don't have permissions on the group
            self.c.sf.getAdminService().getEventContext()
        self.setSecure(self.secure)

[cneves]

As far as I can see, there isn't anything the python omero.gateway could be doing differently. The create session call above is calling omero.clients().createSession which in turn calls "prx = self.getRouter(self.ic).createSession(username, password)", so the attempt of using the username as session key lays deeper in the stack.

Moving to someone who will know better.

[jmoore]

This is expected, though unusual and wrong, behavior. If a previous session is being used as the username , then PermissionsVerifierI will perform a check against the password table using the username as omeName. SessionManagerI, however, first checks whether or not the uuid exists as a session (it has no access to the password). This is a result of the changes made for #2212. The most correct change would probably be to teach the PermissionsVerifierI the same logic as the SessionManagerI, namely to check for an existing session first. A further, but harder, change is to prevent usernames from being created that match existing sessions. In general, though, I don't think this is an issue, because a root user would never knowingly use their own session id as a username, and we should probably take care to not do so during testing.

See:

• ​http://git.openmicroscopy.org/?p=ome.git;a=blob;f=components/blitz/src/ome/services/blitz/fire/SessionManagerI.java;h=07f570e13f5bc9d60c17e93932a1c2fa89f138ef;hb=develop
• ​http://git.openmicroscopy.org/?p=ome.git;a=blob;f=components/blitz/src/ome/services/blitz/fire/PermissionsVerifierI.java;h=a7aed4260269fe8ae84200e0ca11154ab3a70806;hb=develop

[jmoore <josh@…>]

(In [4ea06983d312c06a5e1c61175afac01884a31b0c/ome.git] on branch develop) Improving HasPassword logic of PermissionsVerifierI (See #2212, Fix #3652)