RESTful triggers #58

Closed
opened 2020-06-01 00:54:52 +00:00 by jamie · 2 comments
jamie commented 2020-06-01 00:54:52 +00:00 (Migrated from git.hazaar.io)

To trigger an event at the moment, it must be done via WebSockets, which requires setting up a WebSocket connection with Warlock session and sending the trigger packet. To ease use in some situations, it might be nice to be able to send triggers via HTTP instead of initating the WebSocket protocol connection. We would use the same listening socket as WebSockets, but instead of looking for the Switching Protocols request, we process it as a normal HTTP request.

This of course will need some level of simple authentication so that not anyone can just send triggers. Whether this is a global key, or what might be better is setting up a list of keys that can possible expire or be revoked. This could be stored in a key file (we can use the BTREE file format) and keys can be added/removed via normal WebSockets protocol commands. These keys can maybe even have ACLS or restrict triggers to a set list, or even be trigger specific so that the key is actually used as the trigger name in the request. This might actually be the best option. Although maybe all of the above which would allow access at different levels.

To trigger an event at the moment, it must be done via WebSockets, which requires setting up a WebSocket connection with Warlock session and sending the trigger packet. To ease use in some situations, it might be nice to be able to send triggers via HTTP instead of initating the WebSocket protocol connection. We would use the same listening socket as WebSockets, but instead of looking for the `Switching Protocols` request, we process it as a normal HTTP request. This of course will need some level of simple authentication so that not anyone can just send triggers. Whether this is a global key, or what might be better is setting up a list of keys that can possible expire or be revoked. This could be stored in a key file (we can use the BTREE file format) and keys can be added/removed via normal WebSockets protocol commands. These keys can maybe even have ACLS or restrict triggers to a set list, or even be trigger specific so that the key is actually used as the trigger name in the request. This might actually be the best option. Although maybe all of the above which would allow access at different levels.
jamie commented 2020-06-06 09:52:13 +00:00 (Migrated from git.hazaar.io)

mentioned in merge request !30

mentioned in merge request !30
jamie commented 2020-06-06 09:52:13 +00:00 (Migrated from git.hazaar.io)

created merge request !30 to address this issue

created merge request !30 to address this issue
jamie (Migrated from git.hazaar.io) closed this issue 2024-07-22 08:52:50 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: hazaar/hazaar-warlock#58
No description provided.