Shared bean cant be read in anymore

[graphefruit]

Thats due to somehow changes that "+" is replaced with " " (space)

[RagingCactus]

The (in my opinion) "proper" fix would be to use URL-safe Base64, where + is replaced by - and / is replaced by _. It might be a good idea to use this in the future.

[graphefruit]

Thanks for the support. The issue is that the URL is generated with PROTO-Buff, and I don't know if things could "crash" or don't work anymore

The strange thing is: The url is read correctly, but the URL-Params search is then destroying the "+" into a space, which wasn't before.

[RagingCactus]

The issue is that the URL is generated with PROTO-Buff, and I don't know if things could "crash" or don't work anymore

I'm not talking about the protobuf serialization step, but about the base64 encoding afterwards. I'm talking about line 123 in this example:

https://github.com/graphefruit/Beanconqueror/blob/77c0f1e80eeeef5dca11c43bad90a5751107d9e2/src/services/shareService/share-service.service.ts#L121-L123

uiHelper.encode does "normal" Base64 encoding of the protobuf bytes, see here: https://github.com/graphefruit/Beanconqueror/blob/77c0f1e80eeeef5dca11c43bad90a5751107d9e2/src/services/uiHelper.ts#L162-L164

Normal Base64 contains + and / characters, which need to be encoded if they are used in URLs. This is why normal Base64 is not considered to be "URL-safe". URL-safe Base64 replaces + with - and / with _, which do not have a special meaning in URLs.

I would propose to use the URL-safe Base64 alphabet instead to prevent other possible breakages in the future (which could be done using two simple .replace() calls). You never know how platforms URL-encode and/or URL-decode your shared URLs and in intent/deeplink handlers. You could keep the current workaround for backwards compatibility, but only generate URL-safe links in the future.

[graphefruit]

Fixed with 8.0.3 in the first place.