Using different keys for different events

[aercolino]

A secretKey is currently passed to KnownUser.validateRequestByIntegrationConfig as a simple String.

That's a problem because

1. there is a Secret Key field on each event, which makes it possible to use different keys for different events.
2. However, KnownUser.validateRequestByIntegrationConfig is designed to work at once on all the published integrations,
3. which means it decides on its own whether a queueitToken is valid o not,
4. which means the secretKey it gets must work for all the events it manages,
5. which makes it impossible to use different keys for different events.

If the type was instead a Map: eventId => secretKey, it would work great.

[sarooghi]

Hi @aercolino The secret key is supposed to be used per account (customer) not per event. The secretkey field in the event tab is for legacy support will be removed soon (there will be just one secret key to be set in customer tab). Please let us know if you need to have multiple secret keys (different keys for different events).

[aercolino]

The secretkey field in the event tab is for legacy support will be removed soon

Thanks for sharing it.

We assumed the opposite, that Queue-it's customers had had such a need in the past, and that's why the secret key field was in the event tab in the first place. In fact, years ago we developed our implementation of Known User V2 around that assumption, allowing different keys for different events.

[aercolino]

I just found out that using different keys for different events is the expected configuration, not quite legacy yet.

In the Queue-it /Account /Settings /Integration /KnownUser secret key section, I read:

This is the default secret key... This default key can be overwritten by specifying new KnownUser secret keys on individual event settings.