"Launch URL" transfers to OS empty string

[Niko-CZ]

"Launch URL" for custom URLs stopped to work with one of the latest releases. OS level handlers shows that content of URL is empty after slashes. F.e. I have in URL: ssh1://172.16.100.61 -l userX -pw passX -loghost "hostX" OS receives: ssh1:// *current version is: 1.57.2

[strongbox-mark]

Hi @Niko-CZ - This is on macOS correct? Does a normal https URL work?

How are you verifying what the OS receives?

[Niko-CZ]

Hi Mark, sorry did not put platform details. MacOS Ventura 13.0.1 (22A400). Normal https wotrks fine.

How are you verifying what the OS receives?

For handling of custom URLs I have created application from apple script, and binded URLs to it by adding to Info.plist this part: `

CFBundleURLName URLprocessor CFBundleURLSchemes ssh1 tunnel chrome ie ff

To find the issue point I have added popup in the script. It shows what is received by application: on open location this_URL display dialog "[" & this_URL & "]" There is no issue in script or OS as simple test from terminal: open "ssh1://172.16.100.61 -l userX -pw passX -loghost "hostX"" opened URL. I have noted that issue happens only if URL field in Strongbox has spaces, so ssh1://172.16.100.61- works ssh1://172.16.100.61 -l userX -pw passX -loghost "hostX"- do not work https://172.16.100.61 -x` - do not work also (even it has no sense)

Regards, Niko

[strongbox-mark]

HI @Niko-CZ - Could you insert a %20 instead of a space? i.e. url encode this. e.g.

ssh1://172.16.100.61%20-l%20userX

Does that work?

[Niko-CZ]

Yes, it works. But also other special symbols need to be URL encoded. I suppose you have changed function for URL opening, which is dedicated to http format, right? Correction will not work for our team, as we are using same DB by different team members with Windows, Mac and I can't change URL format. Is it possible to return to old-style URL handler?

[strongbox-mark]

Hi @Niko-CZ - I'll have a look at a way to restore previous behaviour - it's not something we did deliberately to break these more like an unintended consequence of some refactoring I would imagine.

[Niko-CZ]

Thanks a lot for returning back of old behavior in 1.58.0 :) you rock!

[strongbox-mark]

Oh fantastic, I meant to get back to you but it seems like it works, that's great. We automatically URL encode the URL now when launching, and that seems to do the trick.