Provide container session token to and from container service #45

New issue

Closed

opened 2025-12-28 18:12:08 +00:00 by sami · 2 comments

sami commented

2025-12-28 18:12:08 +00:00

Owner

Originally created by @alexvanin on GitHub (May 17, 2021).

Originally assigned to: @cthulhu-rider on GitHub.

There are several ways container session token can be provided to and by container service.

Include session token in container and EACL bodies.

Objects already has session token field in the header, so it makes sense to do the same way with containers and EACL. This way we won't change signatures of RPC services and contract methods.

Include session token in meta headers.

The other way to include session tokens in request and response meta headers. In this case we should update container contract signatures and make additional storage for session tokens there. Also responses do not have token field in meta header yet. It actually doesn't make much sense, because it is meta information and it is not represented in response structures. It is not the case for the session token.

Personally I would go with option (1), because it requires small changes (two extra fields) and it is robust.

Originally created by @alexvanin on GitHub (May 17, 2021). Originally assigned to: @cthulhu-rider on GitHub. There are several ways container session token can be provided to and by container service. ## Include session token in container and EACL bodies. Objects already has session token field in the header, so it makes sense to do the same way with containers and EACL. This way we won't change signatures of RPC services and contract methods. ## Include session token in meta headers. The other way to include session tokens in request and response meta headers. In this case we should update container contract signatures and make additional storage for session tokens there. Also responses do not have token field in meta header yet. It actually doesn't make much sense, because it is meta information and it is not represented in response structures. It is not the case for the session token. --- Personally I would go with option (1), because it requires small changes (two extra fields) and it is robust.

sami closed this issue

2025-12-28 18:12:08 +00:00

sami commented

2025-12-28 18:12:08 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (May 20, 2021):

Option (1) seems more appropriate I think: in the case of creating a container within a delegated session, this information must be permanently reflected in the container itself. Leaving the token outside the structure, we will be forced to always pass it alongside.

On the other hand, this also applies to the signature, which at the moment is always nearby, but not sewn into the container.

Regardless of the approach chosen, I think the token should be present at the same level as the signature.

@cthulhu-rider commented on GitHub (May 20, 2021): Option (1) seems more appropriate I think: in the case of creating a container within a delegated session, this information must be permanently reflected in the container itself. Leaving the token outside the structure, we will be forced to always pass it alongside. On the other hand, this also applies to the signature, which at the moment is always nearby, but not sewn into the container. Regardless of the approach chosen, I think the token should be present at the same level as the signature.

sami commented

2025-12-28 18:12:09 +00:00

Author

Owner

@alexvanin commented on GitHub (May 24, 2021):

After drafting and internal discussion we've decided to:

pass session token in RequestMetaHeader in container.Put, container.Delete and container.SetExtendedACL RPCs,
return session token in GetResponseBody and GetExtendedACLBody,
also return signature of container in GetResponseBody so it will be pretty much the same as GetExtendedACLResponseBody.

There are dependency issues when session token stored right in ExtendedACL and Container structures. It makes sense to keep session token along with signatures and signatures are stored separately in response bodies. That's the reason we expand GetResponseBody with signature field as well.

@alexvanin commented on GitHub (May 24, 2021): After drafting and internal discussion we've decided to: - pass session token in `RequestMetaHeader` in `container.Put`, `container.Delete` and `container.SetExtendedACL` RPCs, - return session token in `GetResponseBody` and `GetExtendedACLBody`, - also return signature of container in `GetResponseBody` so it will be pretty much the same as `GetExtendedACLResponseBody`. There are dependency issues when session token stored right in `ExtendedACL` and `Container` structures. It makes sense to keep session token along with signatures and signatures are stored separately in response bodies. That's the reason we expand `GetResponseBody` with signature field as well.