Skip to content

fix: mount and browse space drives whose display name contains a slash - EXO-89613 - #2070

Merged
ahamdi merged 1 commit into
feature/maintenancefrom
fix/EXO-89613
Sep 3, 2026
Merged

fix: mount and browse space drives whose display name contains a slash - EXO-89613#2070
ahamdi merged 1 commit into
feature/maintenancefrom
fix/EXO-89613

Conversation

@ahamdi

@ahamdi ahamdi commented Sep 3, 2026

Copy link
Copy Markdown
Member

A Space display name holding a '/' was URL-encoded into the WebDAV drive segment as %2F, which StrictHttpFirewall rejects before the request reaches any handler and which, once decoded, split the drive into two path segments so that the identity id could no longer be read back from the path.

A drive is now addressed by its Space pretty name - the very name its JCR drive is created under - while staying presented under its display name in the WebDAV displayname property. Personal drives keep the user full name. toWebDavSegment guards both against any character that cannot survive a single path segment.

The legacy fallback in resolveToJcrPath now compares identity-relative paths only, so a client holding an older spelling of the drive name still resolves.

The 'Map eXo Drives' drawer built the space segment client-side from the display name and is aligned on the same rule.

…h - EXO-89613

A Space display name holding a '/' was URL-encoded into the WebDAV drive
segment as %2F, which StrictHttpFirewall rejects before the request reaches
any handler and which, once decoded, split the drive into two path segments
so that the identity id could no longer be read back from the path.

A drive is now addressed by its Space pretty name - the very name its JCR
drive is created under - while staying presented under its display name in
the WebDAV displayname property. Personal drives keep the user full name.
toWebDavSegment guards both against any character that cannot survive a
single path segment.

The legacy fallback in resolveToJcrPath now compares identity-relative paths
only, so a client holding an older spelling of the drive name still resolves.

The 'Map eXo Drives' drawer built the space segment client-side from the
display name and is aligned on the same rule.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ahamdi ahamdi self-assigned this Sep 3, 2026
@ahamdi
ahamdi requested a review from mkrout September 3, 2026 13:18
@ahamdi
ahamdi enabled auto-merge (squash) September 3, 2026 13:18
@ahamdi
ahamdi merged commit c67d1e7 into feature/maintenance Sep 3, 2026
8 of 9 checks passed
@ahamdi
ahamdi deleted the fix/EXO-89613 branch September 3, 2026 13:27
exo-swf pushed a commit that referenced this pull request Sep 4, 2026
…h - EXO-89613 (#2070)

A Space display name holding a '/' was URL-encoded into the WebDAV drive
segment as %2F, which StrictHttpFirewall rejects before the request reaches
any handler and which, once decoded, split the drive into two path segments
so that the identity id could no longer be read back from the path.

A drive is now addressed by its Space pretty name - the very name its JCR
drive is created under - while staying presented under its display name in
the WebDAV displayname property. Personal drives keep the user full name.
toWebDavSegment guards both against any character that cannot survive a
single path segment.

The legacy fallback in resolveToJcrPath now compares identity-relative paths
only, so a client holding an older spelling of the drive name still resolves.

The 'Map eXo Drives' drawer built the space segment client-side from the
display name and is aligned on the same rule.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants