issue(s) with the web public user

[achessel]

Hi all,

I began playing with the public user and run into some troubles... I configured it following the docs (I am on windows server 2008, using 4.4.8) and:

-the webclient works as advertised (I have access to the public data if I allow the public user to navigate to /webclient, other users are not affected)
-I cannot access private data anymore from the webgateway or webtest (it seems like it tries to access them as public user, fails to get access and stops, not putting up the login prompt).
-If I try to access public data through webgateway, it has a weird behaviour: it works for the 'render_image' pages (ie show the image), but would only display the decoration/gui and no data (neither pixels nor anything else) for the 'img_detail' one. I could not see any errors or warning in any of the logs.
Actually I just tested turning off the public user and while I now can connect to see private data, the webgetway is still weird the same way. I am quite sure that it worked a while back, though...

Any idea what I could be doing wrong/what could be broken?

Thanks
A.

[wmoore]

Hi,

I think you need to go to /webclient/login/ and log in as yourself - then you should be able to access the webgateway & webtest urls. The logic of the 'public user' login is that it only uses that if you're not already logged in. See the flow diagram at https://www.openmicroscopy.org/site/sup ... n-required

Not sure what you mean exactly by "only display decoration/gui". Maybe using browser dev tools/console might show which urls are failing. What regex do you have for your url filter?

Code: Select all

$ bin/omero config get omero.web.public.url_filter


Maybe you could send me the public urls that are not working and I can take a look. E.g. http://nightshade.openmicroscopy.org/we ... l/3925542/

Cheers,

Will.

[achessel]

After an PM exchange with Will, it seems that this may be a bug. Copy pasting 'for posterity' without the links:

Hi will,

Here is the line I entered to set the filter:
bin/omero config set omero.web.public.url_filter '^/webgateway'

Here are two links to an public image. The first should render the image, not the second...

[...]/omero/webgateway/render_image/14350/
[...]/omero/webgateway/img_detail/14350/

Also looking at your flowchart, the problem seems to be that is does not redirect to a login page, just fails with a 404. Here is an image in a private dataset fro example:
[...]/omero/webgateway/img_detail/16811/

Thanks again

Anatole

And will's answer

The problem is not really a permissions one, but seems to be a BUG. I'll have a look at that now.

We're missing /omero/ when constructing urls for the viewer json.
The url that the viewer is trying to reach for json is
[...]/webgateway/imgData/14350/
which is giving a 404, because it should be trying to use
[...]/omero/webgateway/imgData/14350/

The reason you get a 404 for that private url (instead of login page) is that you get logged in as the public user (url has 'webgateway') but then you get a 404 when you try to look up that image, since you don't have permission to view it.

If you try to access an image in OMERO and you don't have permissions, OMERO will simply fail to return it. It doesn't tell you that the image exists. So we can only apply the same logic in the web - if you try to access a url that you don't have permission for, it's a 404.

I wonder if you could paste your reply above into the main forum topic (remove any urls you don't want public). Then I can put my reply in below - that way we keep everyone else informed.

Cheers,

Will.

[achessel]

So it would be an issue due to the windows IIS domain (or however they are called)...
But then why would it work for render_image ?
Also I tried setting url_filter to '^/omero/webgateway' and I had the same behaviour...


For the private images issue: if I understand correctly, it means that if you enable the public user, accessing other webapp that the webclient by private users is kinda broken: they have to know that they should first log in on the webclient?

Thanks again...

A.

[atarkowska]

Hello

I haven't flowed that thread before and don't know exactly the entire story going through PM but I think this is not exactly a problem of a custom prefix. Issue is related to the viewport_server variable.

From the post above I can see that you tried access image via webgateway application directly and that is true that the line above has /webgateway hard-coded if any vieport_server is not set. This string definitely should be replaced by URL dispatcher. Although that problem should be easily resolved by launching full viewer from http://omero/webclient... see how viewport_server is set here. I can confirm that we deployed teaching tool on custom prefix and JSON response is HTTP 200.

Why do you use [...]/omero/webgateway/render_image/14350/ rather then webclient?

If you are writing your own application you need to override that function exactly as webclient does and use your own url like here

I hope it will help.

Thanks
Ola

[wmoore]

Update:

- We are using /webgateway viewer (instead of webclient viewer) because the public url filter keeps /webclient urls private.

- The viewport_server is currently hard-coded to "/webgateway" - see https://trac.openmicroscopy.org.uk/ome/ticket/11451 ticket and PRs to fix this.

- The /omero/webgateway/render_image/... url works fine (since it has the /omero/ in it. The problem with the full viewer at /omero/webgateway/img_detail/... is that it uses Javascript to construct urls for json and image rendering and omits the /omero - so it tries to use /webgateway/render_image/... etc which gets a 404. This has now been fixed in next release (see ticket above).

- You should only have to use /login pages directly for private data under urls that are 'public', e.g. /webgateway. In your case, the /webclient urls should still redirect to webclient/login. Are you sure that /webtest fails to redirect to login page?

Hope this is becoming clearer? Bug fix should help.
NB: You can see the fix is very small (see PRs linked from ticket above), if you want to try that yourself...?

[achessel]

Ok I see, thanks for that. Indeed, the aim eventually is to do a webapp showing images without giving access to the whole of the web client, just selected images (integrating other things, like a postgres database; I have been trying Django with some success despite my relative ignorance of web things). My understanding was that webgateway was the right place for that.
Any idea when the next 4.4 release, including that bugfix, would be? Just to plan things on our end...


Indeed, if only webgateway is public and I try to access webtest it does send me to the login page. It does not if I try to access a private image through webgateway, but that is expected, if I understand correctly. I can see cases where that would be an issue, maybe? Although that's more of a detail I guess. I guess eventually, for a public access of any significant size you would expect to use a dedicated server; so far I am just doing tests on the one server we have...

thanks again
A.

[wmoore]

Next release is in the region of a month's time, but no date fixed yet.

The fix for that webgateway bug (currently waiting to be tested and merged) is:
https://github.com/openmicroscopy/openm ... 1491/files

Once we're happy with it and the PR is merged, you could go ahead and apply that change to
OMERO/lib/python/omeroweb/webgateway/views.py

Good luck with Django - let us know if you need any help extending the OMERO.web framework,

Will