Container+EACL

[cthulhu-rider]

No description provided.

[carpawell]

Can we open it?

[cthulhu-rider]

Can we open it?

sure! Could u pls assist me?

[carpawell]

@roman-khimov, @cthulhu-rider, i suggest:

1. drop session token V1 support, this PR is an extension, i think it is ok to use only v2 token
2. merge fields into a single optional message

As a more radical approach to 1.: do not use an additional token in this API at all: it is only needed for IRs to understand that it is allowed for signer to make this operation, i think it is ok to treat CONTAINER_PUT as a one-time initial CONTAINER_SETEACL

[roman-khimov]

1. For this feature yes, sv1 can be omitted. Any clients using it are API 2.23+ and they all can use sv2. Real clients are almost all converted as well, it's just a matter of a little time.
2. We can require sv2 used in this case to have both PUT and SETEACL verbs, that'd be logically correct and practically acceptable, so additional token field can be avoided completely.

[carpawell]

I have a PoC with the updated version, but i'm still not sure whether we need to complicate session things and have an additional signature field. They are used to ensure that setting eACL is an authorized operation, but if a user is already able to create a container, why not just allow him to change eACL in the same operation? I would treat eACL as a container attribute/field, this would simplify API and server validation. I cannot imagine cases when we have some policies that must allow container creation, but not changing its eACL, even with N3 signatures and complex validation logic.

[roman-khimov]

I think this structure is flexible enough to support different implementations. Ideally signature check should be performed at the contract level, in which case a separate signature for a separate call makes total sense.