SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions.

SpiceDB

looks like the `go` on my path isn't the one from brew. Just a sec...

since we know it _can_ work, is there a reason you really want to use that specific token?

It *is* a fun mystery. In my experience unexpected character limitations can be a sign of injection vulnerabilities, which is what made me want to bring it up. I definitely don't need to use this specific token.

there's a de-facto limit, which is that gRPC is subject to HTTP/2 header length limits

here's the code that enforces it: https://github.com/authzed/spicedb/blob/main/internal/auth/presharedkey.go

FYI, I was on 1.4.0 w/ the local binary, and am able to reproduce the issue w/ the 1.4.0 amd64 docker image
```
docker run --env SPICEDB_GRPC_PRESHARED_KEY='9o5Nnk93O8Am$isH%G#Fav6$7g!cdnP%W0S@E!s2Q7nU$6hrDVIR4Ss4OtTsnhue' --env SPICEDB_GRPC_NO_TLS=true --env SPICEDB_HTTP_NO_TLS=true -p 50051:50051 quay.io/authzed/spicedb:v1.4.0-amd64 serve
```

I'm not a go dev. I probably wouldn't even be able to find an obvious issue :S

I'm also able to reproduce that issue by checking out the v1.4.0 tag

<@!144617890757214209> I wasn't able to reproduce the issue;  the key above worked for a local SpiceDB at HEAD

```
$ SPICEDB_GRPC_PRESHARED_KEY='9o5Nnk93O8Am$isH%G#Fav6$7g!cdnP%W0S@E!s2Q7nU$6hrDVIR4Ss4OtTsnhue' SPICEDB_GRPC_NO_TLS=true SPICEDB_HTTP_NO_TLS=true ./spicedb serve --log-level=trace
3:57PM INF set log level new level=trace
3:57PM INF set tracing provider new provider=none
3:57PM TRC using gRPC auth preshared-key=9o5Nnk93O8Am$isH%G#Fav6$7g!cdnP%W0S@E!s2Q7nU$6hrDVIR4Ss4OtTsnhue
```

in 1.4.0, that was being expanded from the shell into an ENV var of `$6`

```
$ SPICEDB_GRPC_PRESHARED_KEY='9o5Nnk93O8Am$isH%G#Fav6$7g!cdnP%W0S@E!s2Q7nU$6hrDVIR4Ss4OtTsnhue' SPICEDB_GRPC_NO_TLS=true SPICEDB_HTTP_NO_TLS=true ./spicedb serve --log-level=trace
4:01PM INF set log level new level=trace
4:01PM INF set tracing provider new provider=none
4:01PM TRC using gRPC auth preshared-key=9o5Nnk93O8Am%G#Fav6g!cdnP%W0S@E!s2Q7nUhrDVIR4Ss4OtTsnhue
```

you can see the different in key given vs key configured

Thanks guys, appreciate the sanity check. Of course it didn't occur to me to pass the `--log-level`. I'll enforce the alphanumeric limitation on our token generator until the HEAD code makes it into the docker image.

64 chars alphanum is like 350+ bits of entropy, so definitely enough, but good to know I'm not going crazy 🙂

Hi! I'm new to the idea of running authorization as separate part of the stack - but I'm super intrigued.

One question I have is how to translate these permissions to search or query operations in my datastore. Of course, ID lookups totally make sense, but what about a case in which I'm trying to query all records a user has the right to access?

<@!951534988619300884> somebody asked a similar question a few days back, it might be helpful: https://discord.com/channels/844600078504951838/844600078948630559/949019177556000869