tuwrraphael / calendarservice Goto Github PK

A service scope client should be able to request a reminder for a users. It consists of a webhook which is called always x time before the next user's event starts. The reminder expires and must be reinstalled after time to prevent calling inactive clients. It should be implemented by registering a butler callback for the next upcoming event.

The bulter callbacks should be managed when reminders are added, subscribed feeds change, or on change notifications from calendar providers.

CalendarProvider

A CalendarProvider should provide a MaintainNotifications method.

MaintainNotifications(for current config)

• for each feed currently subscribed to in the config
  • check if there is currently a notification channel installed
    • if not create a notification channel id and create the respective webhook with the id
      • set up the butler service to call the MaintainNotification together with the notification channel id shortly before expiration
      • store the channel id together with the expiration and the user
    • if yes, check if the channel is near to expiry
      • in case of expiry renew the channel and store the new expiration
      • install the butler service for the new expiration
• for each notification channel of the user which does not have a feed to which the user subscribed to
  uninstall the webhook and delete the channel

UninstallNotification(for current config ,FeedId)

• for each notification channel uninstall the webhook and delete the channel

MaintainNotification(id)

TBD: like MaintainNotifications but only for a specific notification id

Usage

The MaintainNotifications should be called when the subscribed feeds change or when reminders are added/renewed, but only if there are active reminders for the user, otherwise the UninstallNotifications should be called.

There might be an issue where the butler service is called multiple times at nearly the same time because of similar expiration if MaintainNotifications is called using a config id instead of calling a MaintainNotification with a notification id from the bulter callback.

CalendarConfigurationRespository

TBD: methods to store and retrieve notification channels

There is the tiniest possibility that a man in the middle links a different calendar to a user than expected with those steps:

• user requests calendar linking
• man in the middle intercepts state which was generated for the users oauth2 authorization code flow
• man in the middle requests calendar linking, but stops the process before his authorization code is returned to the CalendarService
• man in the middle returns his authorization code together with the intercepted state from the user to the CalendarService fast enough, before the users authorization code and state is passed

The result is that man in the middles calendar gets linked to users account.

A possible fix would be to add an additional step:

• when the current linking process is done, the new calendar is just a linking candidate (maybe even dont redeem the authorization code yet)
• after redirecting to the app which requested the linking the linking candidate(s) are retrieved
• a linking candidate is finally linked with the users consent in an extra request authenticated with the users bearer token (this time redeem the authorization code of the linking candidate for calendar access/refresh Tokens if not done in the first step)

If the user links an account twice, recognize and replace the tokens instead of adding a second instance.

To list, and to retrieve the config id for deleting a config.