[ome-users] Bad session key

Sebastien Besson (Staff) s.besson at dundee.ac.uk
Fri Apr 10 11:29:44 BST 2015


Hi Paul,

thanks for describing your workflow. It certainly matches one of the use cases we
also had in mind while reviewing the session key usage so we will make sure this is
covered.

In preparation of the improvements discussed in this thread, I opened a first Pull Request
which reviews the existing behaviour and increases the test coverage
https://github.com/openmicroscopy/openmicroscopy/pull/3702
This Request should also increase the visibility of the conflicting properties message
which is only visible in debug mode currently.

We will keep you posted on upcoming Pull Requests.
Best,
Sebastien

On 8 Apr 2015, at 14:57, Paul van Schayck <paul at vanschayck.nl<mailto:paul at vanschayck.nl>> wrote:

Hi Sebastien,

Thanks for the detailed answer. Sorry for not noting that we upgraded
from 5.0.3 to 5.1.0, and thereby missing that the change in behavior
was already in the 5.0.x line.

The reason that we use the session key as login method is, as noted
before, the desire to import images back without requiring user input.
This is also because we run these scripts through OMERO.processor
where no login is possible.

A workaround we've been working on is explicitly specifying all
parameters (port and group) in the cli.invoke() call. These we first
obtain from the BlitzGateway API. However, as these are session
settings, it remains a bit weird for having to re-specify these.
Disabling the strict checking thus makes more sense to me.

In any case, whatever you come up with, the current error message "Bad
session key" is very undescriptive of the problem.

Thanks,

Paul


On Wed, Apr 8, 2015 at 2:31 PM, Sebastien Besson (Staff)
<s.besson at dundee.ac.uk<mailto:s.besson at dundee.ac.uk>> wrote:
Hi Paul,

as always, thanks for the feedback. We also noticed several issues with the
session key usage in the CLI during the 5.1.0 testing which we did not have
time to address.

The issue you described below is not fully 5.1 specific as far as I can
tell.
From a 5.0.8 server, I can reproduce a “Bad session key” error if a group
was
passed while creating the initial connection and this group is not passed
when
joining the session:

$ rm -rf ~/omero/sessions/
$ bin/omero login user-4 at localhost:4064 -g read-only-1
Password:
Created session 4f481d76-cc77-4884-8941-682f1c3b5d6b
(user-4 at localhost:4064). Idle timeout: 10.0 min. Current group: read-only-1
$ bin/omero login -k 4f481d76-cc77-4884-8941-682f1c3b5d6b localhost:4064
Bad session key
$ bin/omero login -k 4f481d76-cc77-4884-8941-682f1c3b5d6b localhost:4064 -g
read-only-1
Joined session 4f481d76-cc77-4884-8941-682f1c3b5d6b (user-4 at localhost:4064).
Idle timeout: 10.0 min. Current group: read-only-1

This particular issue is related to the fact that the check_and_attach()
logic
performs a strict check for properties conflict:
https://github.com/openmicroscopy/openmicroscopy/blob/v5.1.0/components/tools/OmeroPy/src/omero/plugins/sessions.py#L346
https://github.com/openmicroscopy/openmicroscopy/blob/v5.1.0/components/tools/OmeroPy/src/omero/plugins/sessions.py#L410
This implies every property stored in the session file locally will be
tested
against the new connection arguments (including omero.port and omero.group
if
applicable) and throw an error on mismatch.

As mentioned above, we are investigating a series of usability issues with
the
session key usage for the CLI (and potentially other clients). The full
scoping
for these improvements is scheduled for 5.1.2 and hopefully we will have
them
implemented for 5.1.3.

For your particular scenario, one idea to prevent breaking the API might be
to
implement a login option to disable strict property checking while logging
in
using a session key. Any thoughts?

Best regards,
Sebastien


On 8 Apr 2015, at 09:15, Paul van Schayck <paul at vanschayck.nl> wrote:

Dear developers,

We are running local scripts in an OMERO.py environment on an OMERO
server running on localhost using `OMERO.py/bin/omero script run
path/to/script.py`. From this script we are starting the importer
using `cli.invoke()`. For this to work we have copied jars
`OMERO.server/lib/client` to the `OMERO.py/lib/client`. To prevent
users from double login we are passing the session key to
`cli.invoke()` using the `-k` argument.

So far so good, and this has worked for OMERO 5.0. With OMERO 5.1 we
have run into an issue. We suspect this has to do with the new logic
regarding checking whether an import to a specific group/dataset is
allowed. But the exact cause we have not pin pointed.

The error we get during the script is "Bad session key". We can
replicate this by running the import command separately. See below.
What especially got our attention is the "conflicts:
omero.group:dev!=None;" notice.

By explicitly specifying the group "-g dev" during import this is
fixed. But we don't think this is intended. Nor do we think that the
"Bad session key" error is intended.

Thanks,

Paul van Schayck


$ rm -r ~/omero/

$ OMERO.py/bin/omero login -g dev
Server: [localhost:4064]
Username: [PVC]paul
Password:
Created session c5164797-2ae3-4367-8d73-0c51440e2a71
(paul at localhost:4064). Idle timeout: 600.0 min. Current group: dev

$ OMERO.py/bin/omero --debug=DEBUG import -k
c5164797-2ae3-4367-8d73-0c51440e2a71 -d3611 /path/to/import
Server: [localhost:4064]
Skipping c5164797-2ae3-4367-8d73-0c51440e2a71 due to conflicts:
omero.group:dev!=None;
Bad session key

$ OMERO.py/bin/omero sessions file
/home/PVC/omero/sessions/localhost/paul/c5164797-2ae3-4367-8d73-0c51440e2a71

$ cat
/home/PVC/omero/sessions/localhost/paul/c5164797-2ae3-4367-8d73-0c51440e2a71
omero.sess=c5164797-2ae3-4367-8d73-0c51440e2a71
omero.group=dev
omero.user=paul
omero.host=localhost
omero.port=4064


$ OMERO.py/bin/omero sessions list
Server         | User | Group | Session
| Active    | Started
----------------+------+-------+--------------------------------------+-----------+--------------------------
localhost:4064 | paul | dev   | c5164797-2ae3-4367-8d73-0c51440e2a71
| Logged in | Wed Apr  8 10:07:32 2015
(1 row)
_______________________________________________
ome-users mailing list
ome-users at lists.openmicroscopy.org.uk
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users



The University of Dundee is a registered Scottish Charity, No: SC015096

_______________________________________________
ome-users mailing list
ome-users at lists.openmicroscopy.org.uk
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users

_______________________________________________
ome-users mailing list
ome-users at lists.openmicroscopy.org.uk<mailto:ome-users at lists.openmicroscopy.org.uk>
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users


The University of Dundee is a registered Scottish Charity, No: SC015096
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20150410/382d35f2/attachment.html>


More information about the ome-users mailing list