https://authzed.com logo
Join Discord
Powered by
serve-testing token
# spicedb
d
Hey folks, Is there an example of serve-testing integration tests? I am writing a test suite right now and I am trying to enforce the token isolation such that each individual test has its own data suite using its own token. I do this by issuing a "CheckRelationship" request before each test with full_consistency to force a new token. However, I'm seeing that the relationships are being persisted across runs:
Copy code
"rpc error: code = Unknown desc = could not CREATE relationship `customer:A7251DCF-1003-410C-A23F-933253A8FF94#account_executive@employee:dherzig`, as it already existed. If this is persistent, please switch to TOUCH operations or specify a precondition"
Here's the example of my CheckRelationship request (Go SDK):
Copy code
res, err := authzedClient.CheckPermission(ctx, &v1.CheckPermissionRequest{
        Consistency: &v1.Consistency{
            Requirement: &v1.Consistency_FullyConsistent{
                FullyConsistent: true,
            },
        },
        Resource: &v1.ObjectReference{
            ObjectType: "customer",
            ObjectId:   "1234",
        },
        Subject: &v1.SubjectReference{
            Object: &v1.ObjectReference{
                ObjectType: "employee",
                ObjectId:   "dherzig",
            },
        },
        Permission: "view",
    })
And after I insert the relationship using my event bus business logic (a kafka ingestor), I use the following consistency setting to verify the results :
Copy code
Consistency: &v1.Consistency{
            Requirement: &v1.Consistency_AtExactSnapshot{
                AtExactSnapshot: &v1.ZedToken{
                    Token: s.tokenStore.GetToken(),
                },
            },
        },
However I'm seeing that the store is still reporting relationships inserted from a prior run using that token, which to my knowledge should be "fresh" and have nothing
j
the token isolation is the token used in the 
Authorization
header
its based on the client connection
d
Ah!
j
I'll clarify that in the docs
d
So theoretically I could just specify a random authorization header and it would return a fresh data store?
Or does it still enforce that it must be the 
preshared-key
?
Looks like it does not 🧠
j
yes
it does not enforce it
preshared-key isn't used by 
serve-testing
we usually recommend either a test name or a uuid
but you can also use a defined name if you want to share "across" tests
d
OK. One last question, and probably something I need to lookup: can I use PerRPCCredentials to reuse an existing authzed GRPC client and just override the token? Or do I need to recreate the client from scratch and just specify a new bearer token?
j
that I don't know off of the top of my head
d
OK I'll take a look. Thanks!
d
9 Views
PreviousNext
Powered by