<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Paul,
<div class=""><br class="">
</div>
<div class="">thanks for describing your workflow. It certainly matches one of the use cases we</div>
<div class="">also had in mind while reviewing the session key usage so we will make sure this is</div>
<div class="">covered.</div>
<div class=""><br class="">
</div>
<div class="">In preparation of the improvements discussed in this thread, I opened a first Pull Request</div>
<div class="">which reviews the existing behaviour and increases the test coverage</div>
<div class=""><a href="https://github.com/openmicroscopy/openmicroscopy/pull/3702" class="">https://github.com/openmicroscopy/openmicroscopy/pull/3702</a></div>
<div class="">This Request should also increase the visibility of the conflicting properties message</div>
<div class="">which is only visible in debug mode currently.</div>
<div class=""><br class="">
</div>
<div class="">We will keep you posted on upcoming Pull Requests.</div>
<div class="">Best,</div>
<div class="">Sebastien</div>
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On 8 Apr 2015, at 14:57, Paul van Schayck <<a href="mailto:paul@vanschayck.nl" class="">paul@vanschayck.nl</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Hi Sebastien,<br class="">
<br class="">
Thanks for the detailed answer. Sorry for not noting that we upgraded<br class="">
from 5.0.3 to 5.1.0, and thereby missing that the change in behavior<br class="">
was already in the 5.0.x line.<br class="">
<br class="">
The reason that we use the session key as login method is, as noted<br class="">
before, the desire to import images back without requiring user input.<br class="">
This is also because we run these scripts through OMERO.processor<br class="">
where no login is possible.<br class="">
<br class="">
A workaround we've been working on is explicitly specifying all<br class="">
parameters (port and group) in the cli.invoke() call. These we first<br class="">
obtain from the BlitzGateway API. However, as these are session<br class="">
settings, it remains a bit weird for having to re-specify these.<br class="">
Disabling the strict checking thus makes more sense to me.<br class="">
<br class="">
In any case, whatever you come up with, the current error message "Bad<br class="">
session key" is very undescriptive of the problem.<br class="">
<br class="">
Thanks,<br class="">
<br class="">
Paul<br class="">
<br class="">
<br class="">
On Wed, Apr 8, 2015 at 2:31 PM, Sebastien Besson (Staff)<br class="">
<<a href="mailto:s.besson@dundee.ac.uk" class="">s.besson@dundee.ac.uk</a>> wrote:<br class="">
<blockquote type="cite" class="">Hi Paul,<br class="">
<br class="">
as always, thanks for the feedback. We also noticed several issues with the<br class="">
session key usage in the CLI during the 5.1.0 testing which we did not have<br class="">
time to address.<br class="">
<br class="">
The issue you described below is not fully 5.1 specific as far as I can<br class="">
tell.<br class="">
From a 5.0.8 server, I can reproduce a “Bad session key” error if a group<br class="">
was<br class="">
passed while creating the initial connection and this group is not passed<br class="">
when<br class="">
joining the session:<br class="">
<br class="">
$ rm -rf ~/omero/sessions/<br class="">
$ bin/omero login user-4@localhost:4064 -g read-only-1<br class="">
Password:<br class="">
Created session 4f481d76-cc77-4884-8941-682f1c3b5d6b<br class="">
(user-4@localhost:4064). Idle timeout: 10.0 min. Current group: read-only-1<br class="">
$ bin/omero login -k 4f481d76-cc77-4884-8941-682f1c3b5d6b localhost:4064<br class="">
Bad session key<br class="">
$ bin/omero login -k 4f481d76-cc77-4884-8941-682f1c3b5d6b localhost:4064 -g<br class="">
read-only-1<br class="">
Joined session 4f481d76-cc77-4884-8941-682f1c3b5d6b (user-4@localhost:4064).<br class="">
Idle timeout: 10.0 min. Current group: read-only-1<br class="">
<br class="">
This particular issue is related to the fact that the check_and_attach()<br class="">
logic<br class="">
performs a strict check for properties conflict:<br class="">
<a href="https://github.com/openmicroscopy/openmicroscopy/blob/v5.1.0/components/tools/OmeroPy/src/omero/plugins/sessions.py#L346" class="">https://github.com/openmicroscopy/openmicroscopy/blob/v5.1.0/components/tools/OmeroPy/src/omero/plugins/sessions.py#L346</a><br class="">
https://github.com/openmicroscopy/openmicroscopy/blob/v5.1.0/components/tools/OmeroPy/src/omero/plugins/sessions.py#L410<br class="">
This implies every property stored in the session file locally will be<br class="">
tested<br class="">
against the new connection arguments (including omero.port and omero.group<br class="">
if<br class="">
applicable) and throw an error on mismatch.<br class="">
<br class="">
As mentioned above, we are investigating a series of usability issues with<br class="">
the<br class="">
session key usage for the CLI (and potentially other clients). The full<br class="">
scoping<br class="">
for these improvements is scheduled for 5.1.2 and hopefully we will have<br class="">
them<br class="">
implemented for 5.1.3.<br class="">
<br class="">
For your particular scenario, one idea to prevent breaking the API might be<br class="">
to<br class="">
implement a login option to disable strict property checking while logging<br class="">
in<br class="">
using a session key. Any thoughts?<br class="">
<br class="">
Best regards,<br class="">
Sebastien<br class="">
<br class="">
<br class="">
On 8 Apr 2015, at 09:15, Paul van Schayck <paul@vanschayck.nl> wrote:<br class="">
<br class="">
Dear developers,<br class="">
<br class="">
We are running local scripts in an OMERO.py environment on an OMERO<br class="">
server running on localhost using `OMERO.py/bin/omero script run<br class="">
path/to/script.py`. From this script we are starting the importer<br class="">
using `cli.invoke()`. For this to work we have copied jars<br class="">
`OMERO.server/lib/client` to the `OMERO.py/lib/client`. To prevent<br class="">
users from double login we are passing the session key to<br class="">
`cli.invoke()` using the `-k` argument.<br class="">
<br class="">
So far so good, and this has worked for OMERO 5.0. With OMERO 5.1 we<br class="">
have run into an issue. We suspect this has to do with the new logic<br class="">
regarding checking whether an import to a specific group/dataset is<br class="">
allowed. But the exact cause we have not pin pointed.<br class="">
<br class="">
The error we get during the script is "Bad session key". We can<br class="">
replicate this by running the import command separately. See below.<br class="">
What especially got our attention is the "conflicts:<br class="">
omero.group:dev!=None;" notice.<br class="">
<br class="">
By explicitly specifying the group "-g dev" during import this is<br class="">
fixed. But we don't think this is intended. Nor do we think that the<br class="">
"Bad session key" error is intended.<br class="">
<br class="">
Thanks,<br class="">
<br class="">
Paul van Schayck<br class="">
<br class="">
<br class="">
$ rm -r ~/omero/<br class="">
<br class="">
$ OMERO.py/bin/omero login -g dev<br class="">
Server: [localhost:4064]<br class="">
Username: [PVC]paul<br class="">
Password:<br class="">
Created session c5164797-2ae3-4367-8d73-0c51440e2a71<br class="">
(paul@localhost:4064). Idle timeout: 600.0 min. Current group: dev<br class="">
<br class="">
$ OMERO.py/bin/omero --debug=DEBUG import -k<br class="">
c5164797-2ae3-4367-8d73-0c51440e2a71 -d3611 /path/to/import<br class="">
Server: [localhost:4064]<br class="">
Skipping c5164797-2ae3-4367-8d73-0c51440e2a71 due to conflicts:<br class="">
omero.group:dev!=None;<br class="">
Bad session key<br class="">
<br class="">
$ OMERO.py/bin/omero sessions file<br class="">
/home/PVC/omero/sessions/localhost/paul/c5164797-2ae3-4367-8d73-0c51440e2a71<br class="">
<br class="">
$ cat<br class="">
/home/PVC/omero/sessions/localhost/paul/c5164797-2ae3-4367-8d73-0c51440e2a71<br class="">
omero.sess=c5164797-2ae3-4367-8d73-0c51440e2a71<br class="">
omero.group=dev<br class="">
omero.user=paul<br class="">
omero.host=localhost<br class="">
omero.port=4064<br class="">
<br class="">
<br class="">
$ OMERO.py/bin/omero sessions list<br class="">
Server | User | Group | Session<br class="">
| Active | Started<br class="">
----------------+------+-------+--------------------------------------+-----------+--------------------------<br class="">
localhost:4064 | paul | dev | c5164797-2ae3-4367-8d73-0c51440e2a71<br class="">
| Logged in | Wed Apr 8 10:07:32 2015<br class="">
(1 row)<br class="">
_______________________________________________<br class="">
ome-users mailing list<br class="">
ome-users@lists.openmicroscopy.org.uk<br class="">
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users<br class="">
<br class="">
<br class="">
<br class="">
The University of Dundee is a registered Scottish Charity, No: SC015096<br class="">
<br class="">
_______________________________________________<br class="">
ome-users mailing list<br class="">
ome-users@lists.openmicroscopy.org.uk<br class="">
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users<br class="">
<br class="">
</blockquote>
_______________________________________________<br class="">
ome-users mailing list<br class="">
<a href="mailto:ome-users@lists.openmicroscopy.org.uk" class="">ome-users@lists.openmicroscopy.org.uk</a><br class="">
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<span style="font-size:10pt;">The University of Dundee is a registered Scottish Charity, No: SC015096</span>
</body>
</html>