[ome-users] Bad session key

[Sebastien Besson (Staff)]

Hi Paul,

I understand the following sequence of commands is called using the OMERO script
service? Is the full script available somewhere on GitHub?

As you may have been seen, https://github.com/openmicroscopy/openmicroscopy/pull/3720
has been opened to start tackling the property restrictions bug in the scope of 5.1.1. This
may still need to be tested in another context than a sequence of CLI commands.

Best,
Sebastien

> On 13 Apr 2015, at 09:54, Paul van Schayck <paul at vanschayck.nl> wrote:
>
> Hi Sebastien,
>
> Thank you for the PR. The changes look nice. Although, I would argue
> that the error message is still rather cryptic. But I suspect you plan
> on fixing this in someway.
>
> For the record, in the end we opted to go like this (where conn is a
> BlitzGateway object):
>
> cli = omero.cli.CLI()
> cli.loadplugins()
> cmd = []
> cmd.extend(['-q'])
>
> #cmd.extend(['--debug=DEBUG'])
> cmd.extend(["import"])
>
> cmd.extend(["-s", "localhost"])
>
> cmd.extend(["-g", conn.getGroupFromContext().getName()])
> cmd.extend(["-p", "4064"])
>
> cmd.extend(["-k", conn._getSessionId()])
>
> # Skip upgrade check, generation of thumbs, checksum and minmax calculation
> cmd.extend(["--skip", "all"])
>
> This requires us to always specify the group when creating sessions,
> but that's OK.
>
> Kind regards,
>
> Paul
>
> On Fri, Apr 10, 2015 at 12:29 PM, Sebastien Besson (Staff)
> <s.besson at dundee.ac.uk> wrote:
>> 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> 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> 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
>> 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
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users


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