Create chain serialization format #1

New issue

Closed

opened 2023-10-04 08:30:53 +00:00 by fyrchik · 4 comments

fyrchik commented

2023-10-04 08:30:53 +00:00

Owner

No description provided.

alexvanin commented

2023-10-12 12:01:29 +00:00

Owner

Define protobuf message that stores policy. It would be nice to have at least:

chain name,
effect (allow, deny, etc.),
subject (container, object, user, resource, etc.),
object (list, put, store, etc.),
condition (if this equals this, etc.),
data (store any metadata, maybe k:v or just bytes).

Define protobuf message that stores policy. It would be nice to have at least: - chain name, - effect (allow, deny, etc.), - subject (container, object, user, resource, etc.), - object (list, put, store, etc.), - condition (if this equals this, etc.), - data (store any metadata, maybe k:v or just bytes).

fyrchik commented

2023-10-13 16:15:19 +00:00

Author

Owner

Protobuf is not fast to deserialize and in api-go we have wrappers which provide faster serialization.
What about some custom format? It doesn't need to be complex.
Anyway, The final decision can be postponed and/or changed later.

Protobuf is not fast to deserialize and in api-go we have wrappers which provide faster serialization. What about some custom format? It doesn't need to be complex. Anyway, The final decision can be postponed and/or changed later.

aarifullin commented

2023-11-01 15:51:55 +00:00

Member

I agree with @fyrchik

Access policy engine chains are not protocol-specific at all. At the same time we would need to support correct translation between go-types to protobufs the same way we do this in frostfs-sdk-go and this may slows down the development of APE.

I have already tried to generate protobufs for chains (doing the match between fields) and this only led to errors.
It's fine to use serialized JSON-format because:

A chain can be barely huge - we do not need to compress the data
A chain contains conventionally plain-text data

I agree with @fyrchik Access policy engine chains are not protocol-specific at all. At the same time we would need to support correct translation between go-types to protobufs the same way we do this in `frostfs-sdk-go` and this may slows down the development of APE. I have already tried to generate protobufs for chains (doing the match between fields) and this only led to errors. It's fine to use serialized JSON-format because: 1. A chain can be barely huge - we do not need to compress the data 2. A chain contains _conventionally_ plain-text data

dkirillov commented

2024-01-11 09:27:05 +00:00

Member

Current serialization format hash problem with non utf8 bytes in chainid

func TestName(t *testing.T) {
	key, err := keys.NewPrivateKeyFromWIF("L5eVx6HcHaFpQpvjQ3fy29uKDZ8rQ34bfMVx4XfZMm52EqafpNMg") // s3-gw key
	require.NoError(t, err)

	chain1 := &Chain{ID: ID(key.PublicKey().GetScriptHash().BytesBE())}
	data := chain1.Bytes()

	var chain2 Chain
	err = chain2.DecodeBytes(data)
	require.NoError(t, err)

	require.Equal(t, chain1.ID, chain2.ID)
}

Current serialization format hash problem with non utf8 bytes in chainid ```golang func TestName(t *testing.T) { key, err := keys.NewPrivateKeyFromWIF("L5eVx6HcHaFpQpvjQ3fy29uKDZ8rQ34bfMVx4XfZMm52EqafpNMg") // s3-gw key require.NoError(t, err) chain1 := &Chain{ID: ID(key.PublicKey().GetScriptHash().BytesBE())} data := chain1.Bytes() var chain2 Chain err = chain2.DecodeBytes(data) require.NoError(t, err) require.Equal(t, chain1.ID, chain2.ID) } ```