feat:pubsub support for contract call auth #209
Conversation
…s (ContractCall -> ContractCallService)
go.mod
Outdated
| google.golang.org/grpc v1.45.0 | ||
| google.golang.org/protobuf v1.27.1 | ||
| github.com/ory/dockertest/v3 v3.10.0 | ||
| github.com/peggyjv/gravity-bridge/module/v4 v4.0.0-20231211214131-bf2a31eb986f |
There was a problem hiding this comment.
We can point at the v4.0.0 release now without a commit tag.
src/pubsub.rs
Outdated
| s.publisher_domain | ||
| ); | ||
|
|
||
| return; |
There was a problem hiding this comment.
Wouldn't we want the blocklist to be enforced in the authorization handler rather than in the cache? That would have immediate effect, although I suppose a config change requires the process to restart anyway, so I'm not sure there.
In either case, we don't need to process the block list twice, we can create the overall mappings and then filter out blocked entries.
Also one more question: in a for_each like this, is return what we want? I guess it's because it's a code block in the iterator rather than an actual loop?
There was a problem hiding this comment.
Ah I'll move it outside.
Yeah because it's a closure, return acts like continue inside of the for_each method
src/pubsub.rs
Outdated
|
|
||
| // if there is already a default entry for this subscription ID under | ||
| // a different publisher, we remove it from that set of IDs. | ||
| if let Some(p) = subscription_mappings.keys().find(|k| { |
There was a problem hiding this comment.
I think what we're doing here is maybe the reverse order of what we want. We're creating subscription mappings with the publisher as the key, which means we have to do a bunch of weird searching. What if instead the subscription ID is the key, and the publisher is the value? Then it would look like this:
- Write out default subscription mapping
- Run through subscriberIntent mapping -- simply overwrite the publisher key, if the subscriber is using the default it won't change, if they've customized it it will
There was a problem hiding this comment.
Yeah that would be simpler
No description provided.