Correctly handle Slug in POST requests

This is how new URIs get created with Slug headers:

https://github.com/solid/community-server/blob/0fe1bbd0048a07d58b542c7d938df026c08be8d8/src/storage/DataAccessorBasedStore.ts#L307-L310

One important issue here is that there is no call toCanonicalUriPath which means that we might create an identifier here which is not supported by our own server.

There is also no check to see if there are multiple slashes in the slug, which might lead to undefined behaviour internally because there could be references to undefined containers.

In case the generated URI already exists the server will instead generate a new random identifier. Not sure if this is correct since this does not seem to be strictly defined anywhere.

[csarven]

In case the generated URI already exists the server will instead generate a new random identifier. Not sure if this is correct since this does not seem to be strictly defined anywhere.

Right that the Protocol doesn’t say what function servers should run the input through. This is really implementation specific. Clients shouldn’t rely on slugtext being handled deterministically by all servers.

Moreover, client wouldn’t or shouldn’t use Slug if they really want to allocate the URI:

Clients who want to assign a URI to a resource, MUST use PUT and PATCH requests.

Clients who want the server to assign a URI of a resource, MUST use the POST request. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].

For existing resources, this is interesting and important! If say client can determine what the resulting URI will be from slugtext input (well, especially for open source servers, like CSS, and say doesn’t just default to uuid(+slug) or something), then they can find out about the existence of resources in containers where they do not have read permission (eg. Append on C/ and using POST+Slug to see if 201 or 4xx comes back).

Note the table on POST here https://github.com/solid/specification/issues/14#issuecomment-683480525 and I think the following should really be taken as axiom:

Servers allocate unique URIs to resources on POST C/ requests. “C/R exists” is not applicable.

with or without Slug! Don’t get the POST+Slug into a situation where the function depends on C/R existing or not.

For example, avoid using slugtext “as is” ie. generate uuid+slug – something unguessable, or perhaps only allow slugtext “as is” in certain cases eg. having Read, Append on C/ will grant the user from knowing whether something exists or not. So, POST C/ with Slug: R where C/R already exists can then maybe respond with 409 or something.

So IMO, if a server allows Slug, it should consider the above.

BTW, if the above is reasoning is agreeable - not necessarily the exact text or the implementation here, I can try to make this more apparent in the Protocol.

what is expected when doing a POST with slug a/b, a single resource with name a%2Fb or a resource a/ and a resource a/b?

I would disallow it. @csarven?

I agree that’d be simplest for the server and the outcome is least confusing for the client (given possible outcomes).

[joachimvh]

For example, avoid using slugtext “as is” ie. generate uuid+slug – something unguessable, or perhaps only allow slugtext “as is” in certain cases eg. having Read, Append on C/ will grant the user from knowing whether something exists or not. So, POST C/ with Slug: R where C/R already exists can then maybe respond with 409 or something.

In CSS, a POST succeeding is independent of C/R existing, but the generated URI will be different so that way some information is leaked. In the future we could look into making the part that generates the URI based on a slug injectable, so if needed something can be injected that obfuscates this.

BTW, if the above is reasoning is agreeable - not necessarily the exact text or the implementation here, I can try to make this more apparent in the Protocol.

I agree with all of the above, and it would be useful to have a bit more official information on how the slug should be handled.

I would disallow it. @csarven?

I agree that’d be simplest for the server and the outcome is least confusing for the client (given possible outcomes).

@BelgianNoise, adding this change to your implementation would then also require rewriting the tests that incorrectly use POST like this, so feel free to not fix the slash part yet in case that would be too much.