events: usage of api-keys in generated links for not public forums

events: usage of api-keys in generated links for not public forums
0

Feature

usage of api-keys in generated calendar-subscribe-links for not public forums

Description

Allow enabling in the config for “generating calendar subscribe links with included user-api-key”

  • on enable, it needs a popup for creating a client api-key user can delete in their config.
    (if possible, generate api key with only access to the calendar data, not for other content like posts or messages)

  • on disable, it needs to warn for all used links with api key are not longer functional. reenable creates a new key and does not bring old links back working!

  • warn to not give your calender-subscribe-links with api key to other persons, untrusted services or post it.

Use Case

i want to add the event calendar of my not public forum to my google calenders by add the ics link to google-calendar

@angus, the pr was for this request right?

PR review

Issues

  • Rails error when routing to ‘/calendar-events/api_keys.json’ without login.
  • API key is attached to the url even when the forum is public(a condition should be added to detect whether the forum is private or public).

Positive Tests

  • The api key is not attached if the user isn’t logged in.

Concerns

  • Is it safe to send the api keys over from the url itself.
1 Like

I have this functionality deployed on my private forum and it only takes 5 minutes to configure, so I’m not sure it justifies the programatic approach.

Here’s how to set this up:

  • create a user account and name it appropriately (service, automation,…)
  • goto /admin/users/{user_id} for this new account
  • lock trust level to tl0
  • silence user (prevent from posting)
  • create API key for this user
  • acquire the calendar subscribe link and attach api_username and api_key at the end:
    webcal://forum_name/c/category_name/l/calendar.ics?time_zone=tz&api_username={account_username}&api_key={account_key}
  • publish this link on your forum (for appropriate audience) with the disclaimer NOT to share this api_key outside your forum
  • publish instructions for importing this link to popular online calendars

HTH

@md-misko, Thanks for your feedback.
The thing is, we already have a PR on our repository so we though we’d merge it if it was properly done or suggest some changes.

1 Like

Ah, I didn’t realise you didn’t have sufficient permissions to review the PR directly in the repository (you’ll need to accept github invite first). Sorry.

I’ve given you “maintain” rights for the discourse-events repository which will allow you to review the PR directly in Github. Use the “Review” feature to give feedback directly to the person who made the PR.

Ping me here when you’ve done that and I’ll review your review.

2 Likes

I’ve accepted the invite. Should I write the review on github itself?

Cool. I’ve added my comments there. Ready for the review of review :wink: .

2 Likes

After Discourse update to 2.4.0.beta7 there is a warning in the /admin, related to the webcal subscription link (it passes api_username and api_key as part of the request instead of using the header: see details in the link below).

We detected an API request using a deprecated authentication method. Please update it to use header based auth.

@fzngagan is this going to break the ability to subscribe to webcals for all the private forums?

Is it possible to support header based authentication for importing webcal (by negotiating header based auth with the calendar client upon webcal request)?

1 Like

Update: this has been taken into account by the Discourse team, as it also affects rss for private forums, so hopefully this will be resolved in the core.

2 Likes

Update: what is the plan for webcal?

The only API endpoints that will not be affected and will continue to have support for credentials in query parameters will be requests to RSS feeds and the Mail Receiver endpoint.

1 Like