RFC-25: [Superseded by RFC-29] App Access Rule - followup to New App Data Access APIs

General Request for Comments (RFC)
, , ,
10

Hi there,

thanks as always for publishing this RFC.

  • I also do not think it necessary to add another (self-proclaimed!) standard to the mix, especially when it requires its own SDK to be used. IMO, the current webhooks implementation is sufficient. Unless you’re telling us that you want to migrate all webhooks to this, I’d like to rather avoid it. It adds unnecessary complexity. If you were to avoid the binary format, my acceptance might be higher, because it looks like it may be usable without an extra dependency then, but I still think it’s unnecessary.
  • siteIds or cloudIds (they are the same, right?) are not a concept that exists consistently in Connect apps, so receiving Webhooks with it would be hard to process unless the clientKey is also included. Would the webhooks received by Connect apps use the same authorization scheme as the other webhooks? Because those JWTs contain the clientKey, in which case this point is moot
  • Question: I am curious what would happen to, for example, Macros that are in a space that gets restricted at some point and should then be rendered. How would that behave? Found the answer in RFC-14, never mind

Cheers,
Tobi