mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-07-13 00:52:01 -04:00
b6a4a66aef
Review feedback: split the anchor/path and path/suffix on the structural delimiter ":/" instead of a bare ":". Since the path and suffix always start with "/", ":/" is the real delimiter, and a ":" *inside* a file or directory name (which OpenCloud allows but MS Graph/OneDrive forbid) is kept as part of the path instead of being mistaken for a separator. A ":" sitting at a segment boundary (e.g. a name ending in ":") stays ambiguous and must be percent-encoded as "%3A": the split works on the literal ":/", so "%3A" is never a delimiter and decodes back to ":". This is now documented in the code and the acceptance feature. Tests: colon inside a name (with and without a suffix), the Stat path carrying the colon, and the "%3A" boundary escape.
122 lines
4.7 KiB
Gherkin
122 lines
4.7 KiB
Gherkin
Feature: colon-syntax path lookup on the Graph API
|
|
As a client
|
|
I want to address drive items by path using colon-syntax URLs on the Graph API
|
|
So that I do not have to walk the path with successive lookups before issuing a request
|
|
|
|
The colon-syntax shapes recognised by the path-lookup middleware are:
|
|
|
|
/graph/{version}/drives/{driveID}/root:/<path>[:/<suffix>][:]
|
|
/graph/{version}/drives/{driveID}/items/{itemID}:/<relativePath>[:/<suffix>][:]
|
|
|
|
Both /v1.0 and /v1beta1 are supported. NOT_FOUND and PERMISSION_DENIED
|
|
collapse to 404 so the middleware never discloses the existence of
|
|
resources the caller is not allowed to see.
|
|
|
|
The delimiter is ":/", so a raw ':' inside a file or directory name is kept
|
|
as part of the path. A ':' at a segment boundary (e.g. a name ending in ':')
|
|
is ambiguous and must be percent-encoded as "%3A" to be addressed. MS Graph
|
|
and OneDrive sidestep this by forbidding ':' in names entirely; OpenCloud
|
|
allows it (via WebDAV), so the "%3A" escape is how such names are reached
|
|
here.
|
|
|
|
Background:
|
|
Given user "Alice" has been created with default attributes
|
|
And user "Alice" has created folder "folder1"
|
|
And user "Alice" has created folder "folder1/sub"
|
|
And user "Alice" has uploaded file with content "hello" to "folder1/file.txt"
|
|
And user "Alice" has uploaded file with content "deep" to "folder1/sub/deep.txt"
|
|
|
|
|
|
Scenario: get a drive item by root-anchored colon path
|
|
When user "Alice" gets the drive item with colon path "folder1/file.txt" of space "Personal" using the Graph API version "v1.0"
|
|
Then the HTTP status code should be "200"
|
|
And the JSON data of the response should match
|
|
"""
|
|
{
|
|
"type": "object",
|
|
"required": ["id", "name", "parentReference"],
|
|
"properties": {
|
|
"id": {
|
|
"type": "string",
|
|
"pattern": "^%file_id_pattern%$"
|
|
},
|
|
"name": {
|
|
"const": "file.txt"
|
|
}
|
|
}
|
|
}
|
|
"""
|
|
|
|
|
|
Scenario: get a drive item by root-anchored colon path with a deep path
|
|
When user "Alice" gets the drive item with colon path "folder1/sub/deep.txt" of space "Personal" using the Graph API version "v1.0"
|
|
Then the HTTP status code should be "200"
|
|
And the JSON data of the response should match
|
|
"""
|
|
{
|
|
"type": "object",
|
|
"required": ["id", "name"],
|
|
"properties": {
|
|
"name": {
|
|
"const": "deep.txt"
|
|
}
|
|
}
|
|
}
|
|
"""
|
|
|
|
|
|
Scenario: get a drive item by root-anchored colon path with a trailing colon
|
|
When user "Alice" gets the drive item with colon path "folder1/file.txt" of space "Personal" with trailing colon using the Graph API version "v1.0"
|
|
Then the HTTP status code should be "200"
|
|
And the JSON data of the response should match
|
|
"""
|
|
{
|
|
"type": "object",
|
|
"required": ["id", "name"],
|
|
"properties": {
|
|
"name": {
|
|
"const": "file.txt"
|
|
}
|
|
}
|
|
}
|
|
"""
|
|
|
|
|
|
Scenario: get a drive item by item-anchored colon path
|
|
When user "Alice" gets the drive item with colon path "file.txt" relative to folder "folder1" of space "Personal" using the Graph API version "v1.0"
|
|
Then the HTTP status code should be "200"
|
|
And the JSON data of the response should match
|
|
"""
|
|
{
|
|
"type": "object",
|
|
"required": ["id", "name"],
|
|
"properties": {
|
|
"name": {
|
|
"const": "file.txt"
|
|
}
|
|
}
|
|
}
|
|
"""
|
|
|
|
|
|
Scenario: list permissions of a drive item via colon path with a sub-route suffix on v1beta1
|
|
# Exercises the "/<path>:/<suffix>" rewrite shape and, at the same time,
|
|
# the v1beta1 mount of the middleware. The /permissions sub-route is only
|
|
# registered at /v1beta1/, and the canonical /v1beta1 GetDriveItem
|
|
# handler is share-jail-only, so this is the cleanest way to assert that
|
|
# the v1beta1 colon-syntax path actually reaches a working handler for
|
|
# regular drive items.
|
|
When user "Alice" lists permissions of the drive item with colon path "folder1" of space "Personal" using the Graph API version "v1beta1"
|
|
Then the HTTP status code should be "200"
|
|
|
|
|
|
Scenario: non-existent colon path returns 404
|
|
When user "Alice" gets the drive item with colon path "folder1/does-not-exist.txt" of space "Personal" using the Graph API version "v1.0"
|
|
Then the HTTP status code should be "404"
|
|
|
|
|
|
Scenario: another user cannot disclose existence of a resource via colon path
|
|
Given user "Brian" has been created with default attributes
|
|
When user "Brian" gets the drive item with colon path "folder1/file.txt" of the personal space of "Alice" using the Graph API version "v1.0"
|
|
Then the HTTP status code should be "404"
|