0

In TB78, configuring CalDAV with user authentication works fine. However, iCalendar (*.ics) seem to assume no authentication required. The related add-ons are either CalDAV, Exchange, or similarly not ICS managing.

Authentication is done either by traditional username/password (similar to Lightning's handling of CalDAV) or an API key. The latter is usually done with a HTTP header, as in curl -H "Authorization: Key ${API_KEY}" https://.../mycal.ics.

I'm interested in methods that might include:

  • a direct add-on, though I haven't found it yet
  • a way to inject a header to select TB/Lightning outbound connections
  • a way to have TB/Lightning use an external program that returns the file (without requiring me to "import" the file manually each time)

The two workarounds I've been able to think of (and implement, to some degree):

  1. Since I control the server and the rev-proxy in front of it, I fake a URL with redirection that takes https://my.url/api/${API_KEY}/real_path, and converts it to https://my.url/real_path with the header Authorization: Key ${API_KEY}. The problem with this is that the API key is leaked in the rev-proxy logs; this is a controlled bleed but a bleed nonetheless.

  2. Have an external program periodically update a local file (combination of cron or Task Scheduler, with curl or similar). This requires me to tell Lightning that it's still a network iCal file, but use an URL of file:///c:/....

The end-goal is to be self-contained with TB/Lightning, not relying on external task-schedulers (and if possible, external programs).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.