login password with '+' seems to invalid authentication

[DrKenHo-crick]

Problem:
When a user has a password with a '+' sign in it, QuPath will not authenticate properly with OMERO. OMERO browser app works fine. I had a quick look at the code, I suspect that QuPath creating ByteBuffer and converting to byte part from line 179.

Qupath details:
Version: 0.3.2
Build time: 2022-01-17, 08:50
Latest commit tag: '71884c6'

Java version: 16.0.2
Java vendor: Eclipse Foundation - https://adoptium.net/
Java home: /Applications/QuPath.app/Contents/runtime/Contents/Home

Operating system: Mac OS X - 10.15.7
Architecture: x86_64

qupath-extension-omero-0.3.0.jar

[melvingelbard]

Hi @DrKenHo-crick ,

This is a known problem from using the OMERO extension for servers that require credentials with a password containing special characters. This issue also arises with other special characters (e.g. &, +, ..).
If I remember correctly, these special characters are converted when sending the JSON over, and therefore cannot be validated against the 'actual' password stored on the OMERO side. Unfortunately I do not have a solution for this at the moment. Suggestions are welcome!

[joshmoore]

Hi all,

just to clarify, AFAIK, there are no current issues in having special characters in your password on the OMERO.web and OMERO.server side. @melvingelbard, are you thinking then that something happens between the QuPath extension and OMERO.web? e.g. here

https://github.com/qupath/qupath-extension-omero/blob/ab35609d6fb88388eb4da6e108862d4402daac31/src/main/java/qupath/lib/images/servers/omero/OmeroWebClient.java#L178-L196

[melvingelbard]

Hi @joshmoore ,

Yes, that's it. Nothing is wrong on the OMERO side, it's rather on the QuPath extension side that the problem mentioned above occurs.

[joshmoore]

@melvingelbard: is there any easy-ish way (e.g. unit-test or man-in-the-middle recording) to print out what gets POSTed to OMERO.web?

[melvingelbard]

I'm not exactly sure to be honest. I used to simply debug the code with Eclipse to check what gets written to the OutputStream, however at debug level that might not reveal anything suspicious yet.. When this issue arose for the first time (more than 6 months ago), I believe I tried sending that request to localhost and figured the problem lied there.