Extend abstract collect classes to allow custom diffraction viewer

[matyson]

I am adding a site_diffraction_viewer method to the AbstractCollect classes in order to extend the display_image call to accept a site specific diffraction viewer implementation. Defaults to adxv_notify for compatibility

[marcus-oscarsson]

Good idea !

[matyson]

I also want to include the host address of the viewer application because at MAXIV we usually start the viewer application in the same machine as the browser so i thought it would be practical to just intercept the request's remote address for this one.

But maybe it make sense to turn it into a configuration somehow, unless there's a way of accessing mxcubeweb context variables from mxcubecore? Or to extend the detector adapter and inject this dependency?

[marcus-oscarsson]

Could that be part of your "collect" configuration and that hardware object ? I mean the code that opens the actual viewer could take care of where to open it ?

For the record, I'm not sure that collect is the best place to have this sort of logic, its where it is for the moment. We might consider to move this elsewhere (not sure where at the moment), maybe something to think about as well. Keeping it on "collect" is fine for the time being.

[epanepucci]

Updating the HWO config is not an option as we have clients connecting from different IP addresses.
The use case we envision is:

1. user connects to mxcube from IP-A
2. user starts diffraction viewer on IP-A
3. mesh scans and clicks on a cell to call display_image
4. mxcubecore calls the specific diffraction viewer running on IP-A machine to load and display the corresponding image

We want to avoid having all instances of a diffraction viewer react to this.

Basically, can mxcubecore know the IP address of the requesting client?

[marcus-oscarsson]

I see, I think I misunderstood the usage of host. So what you want to do is to start the viewer om the client side ? I think this is rather infrastructure dependent at-leat in your case. As I understand it you use a VPN and the user logs into a computer that runs the browser with MXCuBE and you would like to start the viewer there ?.

I think there is some way to launch external applications from browsers, like is done with zoom for instance. This would be a general solution. Otherwise, yes you could figure out from where/who the "call" is coming but this is/can also be infrastructure dependent. The real IP might be hidden by proxies other other mechanisms.

[epanepucci]

fully agree that it's infra dependent but in our case it would help.
we do have mechanisms to advertise the client IP address to mxcubecore (mainly our tango-keystore) but if the info is already readily available from mxcubeweb I don't see why not use it.

[marcus-oscarsson]

You can try request.remote_addr and if that does not work you need to use ProxyFix (https://flask.palletsprojects.com/en/stable/deploying/proxy_fix/). Its probably a good idea to add the later in anyways.

[matyson]

Ok, i will just keep it as is and try to work something out. Thanks for the input

[matyson]

With the usecase that @epanepucci proposed in mind we can forward the unknown client address through the detector_adapter call in the frontend by accessing the request object through this

[marcus-oscarsson]

Just a thought, can you use something like: albula://open?file=/tmp/test.diff" and add Albula as a mime type handler.
If you are using linux, you ould do like this: https://wiki.scanframe.com/Configuration/Linux/xdg-register-protocol

window.location.href = "albula-view://open?file=/tmp/test.diff";

You would have to make a script albula-view that takes care of parsing the file argument and open Albula with it

Might work if you have Albula installed on the computer running the browser

[marcus-oscarsson]

Working with IP addresses can quickly become quite complicated for doing this sort of thing, but you can try.

[marcus-oscarsson]

I guess this is still DRAFT/WIP ?

[matyson]

I reverted so that it doesn't break mxcube/mxcubeweb#2113 and I can explore alternative solutions to the ip problem in another PR. Sorry for dragging this discussion.

[marcus-oscarsson]

No problem at all @matyson, just wanted to be sure :)