Do not allow clients to set guid for Topic, Viewpoint, Document Reference, Comment

[lasselindqvist]

This issue is opened due to b4e86e5

I feel like this presents bad design.

Some downsides of the design:

1. It introduces an easy possibility of denial-of-service attacks if server allows client to generate the guids, forcing bad hashcodes to be used in the server. Of course the server can deny client guids by the analysis of whether it should, is difficult.
2. The guid should be similar to database primary keys. The server should generate it and it should be immutable.
3. The suggested API includes a lot of optionality. Optionality fragments the API when realistically not all vendors will implement the functionality.

Instead I suggest the API will start including an optional field called client_id. guid will be left as server generated and immutable. client_id can be given by the client and can be used by the server to merge newly posted items to existing ones. In case that happens, the server would need to respond with a proper HTTP response code, such as 303 See Other (or maybe something else more suitable).

This suggestion would also cover the originally intended use case mentioned in #189

[Amoki]

BCF is built for compatibility. If the GUID changes each time the BCF is used with a different app, it becomes very hard to follow.

I don't think validating a UUID v4 (a standard format supported by all major languages and databases) is difficult.
The GUID shouldn't be your database primary key. Each topic should have an id for internal references, eventually hidden from users. Each GUID is unique in the scope of a project, not in the scope of the database. As BCF routes use the couple project_id + guid, which is always unique, I see no reason to expose the PK in JSONs.

[lasselindqvist]

BCF is built for compatibility. If the GUID changes each time the BCF is used with a different app, it becomes very hard to follow.

I don't think validating a UUID v4 (a standard format supported by all major languages and databases) is difficult.
The GUID shouldn't be your database primary key. Each topic should have an id for internal references, eventually hidden from users. Each GUID is unique in the scope of a project, not in the scope of the database. As BCF routes use the couple project_id + guid, which is always unique, I see no reason to expose the PK in JSONs.

Sorry for the confusion. It is definitely not my intention to say the GUID should be a primary key in a database. I mean it should be like that, unique, immutable and always exist. If anyone wants to make it a primary (composite primary?) key, go ahead.
But I am saying that clients should not be allowed to choose the GUID.

[GeorgDangl]

If I remember correctly, our reasoning in the group was that BCF topics might not only be created in some centralized systems, but often in client applications as well. For this, the feature to allow clients to specify the GUID was created.

Generally, one of the big advantages of GUIDs over other keys is the possibility of decentralized key creation and later merging.

Imagine a scenario where multiple users use different systems to create issues, and then later upload those to a BCF server. IF you want to have the option to continue working on these issues in the original systems, you'll need to reimport them again, which should preserve the originally assigned GUIDs at creation time.

I'm not sure what you mean with your first point, the possibility of a DoS attack. Do you mean that non-sequential guids could slow down insertion of indexed rows in a table? Would this be different if a specific client_id property were used?

[lasselindqvist]

If I remember correctly, our reasoning in the group was that BCF topics might not only be created in some centralized systems, but often in client applications as well. For this, the feature to allow clients to specify the GUID was created.

Generally, one of the big advantages of GUIDs over other keys is the possibility of decentralized key creation and later merging.

Imagine a scenario where multiple users use different systems to create issues, and then later upload those to a BCF server. IF you want to have the option to continue working on these issues in the original systems, you'll need to reimport them again, which should preserve the originally assigned GUIDs at creation time.

I'm not sure what you mean with your first point, the possibility of a DoS attack. Do you mean that non-sequential guids could slow down insertion of indexed rows in a table? Would this be different if a specific client_id property were used?

Yeah, true that the same dos issues could be present with client_id version, if it was used in similar caches or indexes.

I do think that client_id would provide the same share first, upload later workflow possibility as mutable guids, but with a clearer design. client_id would be persisted in the shared BCF files and when some later edition of them would be uploaded to a server, it would merge that with a copy that was earlier uploaded by some different user. (Of course it would be nice if all users would be online-only allowing everyone to have up-to-date copy of the common data).

[jasollien]

I see your point regaring optionality Lasse.

1. I do not think it will be a security issue, as a guid specifies a set of valid characters, and must be on that given formats.
2. This can be decided freely on the server still as mentioned above.
3. The reason for keeping it optional, is to make it easier for "smaller clients" to create new topics (or other entities), without having to handle the error in case of a topic with the same guid already existing.

A small note:
This change is actually already supported already in the BCF file format. The change here is to adopt that in the BCF-API.

[ykulbak]

This issue was discussed in the Open CDE Hackathon and it was decided to keep the current proposal as specified in #189