fix(appstore): use URL-safe base64 encoding for user content proxy URLs

[edward-ly]

Summary

Some app screenshot URLs in the proxy server may include the '/' character in their base64 encoding, but since '/' is a prohibited character for file names, the computed proxy server URL was invalid and such screenshots would fail to be retrieved (or rather, the screenshots weren't saved to begin with because of this). This is addressed by making the encoding URL-safe (e.g. replacing / and + with _ and -, respectively).

Accompanies nextcloud/usercontent.apps.nextcloud.com#25.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

[edward-ly]

/backport to stable34

[edward-ly]

/backport to stable33

[edward-ly]

/backport to stable32

[edward-ly]

/backport to stable35

[susnux]

Usually url safe encoding also strips off the = padding

[edward-ly]

Usually url safe encoding also strips off the = padding

Sure, but Python doesn't trim the =, probably because you wouldn't be able to decode and get back the original URL if you do.

[susnux]

Just asking because = also has special meaning in URLs and usually you remove the padding - you can always add it back later like

def urlsafe_b64decode_nopad(data: bytes) -> bytes:
    pad = b'=' * (4 - (len(data) & 3))
    return base64.urlsafe_b64decode(data + pad)

But if this is not needed here then ok :)

[edward-ly]

Ah right, that is true. Still, we haven't had any issues with the = so far; only the / has been causing real problems.