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):
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 tohttps://my.url/real_path
with the headerAuthorization: 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.Have an external program periodically update a local file (combination of
cron
or Task Scheduler, withcurl
or similar). This requires me to tell Lightning that it's still a network iCal file, but use an URL offile:///c:/...
.
The end-goal is to be self-contained with TB/Lightning, not relying on external task-schedulers (and if possible, external programs).