The problem here seems to be while reading the api key. It can’t be read of once its created in latest discourse.
Note There’s some change in the discourse user api key handling. This means we’ll be dropping support for webcal for private forums temporarily. We’ll have to build our own UI for generating those keys.
This is being worked on here: https://github.com/paviliondev/discourse-events/tree/webcal-api-key
p.s.
[*]This feature is merged.
The thing is working. The only issue is, due to the change in discourse, users won’t be able to see their api key via the UI. they need to generate a key and put it themselves. I’m yet to spec it finally.
I’m not sure, I have a user with a user api key and when I pass webcal://discourse.forum.tld/c/category/subcategory/l/calendar.ics?time_zone=tz&api_username=apiuser&api_key=apikey I still get the error: You are not permitted to view the requested resource.
Just pass, user_api_key param to the url you can see in the subscribe list. Make sure its an api key associated with a user.
Nope, still the same. I’ve created a new user api key, copied the Subscribe link and appended the user_api_key, tried both category and subcategory Calendar with:
webcal://discourse.forum.tld/c/category/l/calendar.ics?time_zone=tz&user_api_key=apikey
Is this the correct syntax? Is there anything else that needs to be enabled on the server? Are there any server log I can provide?
Are you trying to connect it to google?
I would suggest adding http instead of webcal
No, I’m opening it in directly in the incognito tab in the browser, replacing webcal with https (which worked before and should also work now).
It returns http 403 forbidden
Are you positive its a not a global api key but a key associated with a user?
I’ll check now. Was wrestling some configuration mess I created on my dev setup.
p.s.
The api keys used there are different. Generate one via
http://siteurl/my/preferences/apps
We’ll be dropping support for api keys automatically appearing in the urls though. This is due to a core api change.
I’m also writing documentation for events plugin. I’ll highlight this fact in the documentation.
Isn’t this only supported for apps to create user_api_keys via API only. There is no UI for users to create those keys AFAIK: https://meta.discourse.org/t/user-api-keys-specification/48536
How will this enable private forums to access rss or webcal type links then? The core team was alerted to such scenarios: https://meta.discourse.org/t/discourse-api-documentation/22706/265?u=md-misko and were preparing some workarounds?
https://meta.discourse.org/t/discourse-api-documentation/22706/291?u=md-misko
https://meta.discourse.org/t/discourse-api-documentation/22706/292?u=md-misko
Can you check with the team what the current status is. This might already work, since the official calendar-plugin and bookmark reminders should be able to synch with external calendars.
Having a look now.
Thanks for this input.
https://meta.discourse.org/t/discourse-2-5-0-beta3-release-notes/148766/2
This seems promising.
https://meta.discourse.org/t/question-regarding-icalendar-feed-for-bookmark-reminders/149048
Have asked the question here. If this works, I’ll do exactly what they did to make our ical feed work.
p.s.
Have a look at this
https://meta.discourse.org/t/sync-bookmark-reminders-with-your-favorite-calendar-app/144954
This is it! It does work, and it works exactly as the first option for the the webcal link used to work: with appending username and admin generated api_key.
If api generated user_api_key also works in the future than we can have complete functionality restored.
If possible, please implement both versions in events plugin: I’m using a dedicated service user (silenced and TL0) with admin generated username/api_key for webcal access rather than personal user keys—it is a single link published on a private forum and I find it easier to manage then per user links, but both can be useful.
I’m still waiting to see if the sync part is working online, but this will take some time, because cloud calendars only sync every few hours. I expect it will work and I will let you know when it does.
It wasn’t the admin generated key. It was automatically generated but was a user_api_key as you can generate both of them via code.
I’m not sure yet whether admin generated keys should be in the URL.
You are talking about the Subscribe button generated webcal link? I believe it was user_api_key there.
But this also worked when using a webcal link and manually appending &username=USER&api_key=KEY, used not with all users type key (this would be mega bad) but with a single user api_key.
This user can then be silenced (cannot post on the forum), and the api_key is only used for webcal sync and nothing else.
This is primarily useful for private forums, where even this kind of link with a restricted user api_key is never shared publicly.
And it is the same principle as the bookmarks example above.
I hear you but I’m thinking to be in sync with discourse here.
I’ll allow support for this type of api keys when they arrive. Thoughts?
https://meta.discourse.org/t/user-api-keys-specification/48536/36?u=fzngagan
@angus your thoughts?
Definitely best to be in sync with core, but will you consider implementing both types if both remain in core?
Currently there is the &username=user&api_key=key approach that is implemented and working, and if I understood Falco correctly he will also add support for the user_api_key?
Either works for me, as long as at least one of them work for private forums 
).
Let’see how Falco approches this one, if I understand correctly this key will still be available only once, when first generated.
Which means that the user will have to succesfuly copy the webcal link the first time they open the Subscribe button? And then save it somewhere, if they want to use it again later in another calendar app (I can predict most won’t remember to save it, or if they do it will definitely NOT be in a secure way). Unless one key is only redeemable once.
And what will happen, if they click the Subscribe button again? Old key is revoked? New one generated? Another key generated?
This is much more work and more confusing for the end user then a single link. But let’s see how it will be imemented in core first 
This will be dropped as it’s not supported in the core to read a key after its created. If the user absolutely need to sync to some closed site’s calendar, they will have to go the long way. Also, this is already causing a js console error.
If you think about it, you’re essentially allowing google or another app to see your account. It better be secure.
I agree that user_api_key is the preferred way for end users to self generate user api key, which gives access to 3rd party apps, but only if any such key can only be used for a single connected app, and is limited to a specific permissions only (which I believe is how this is intended to work).
When using admin generated keys it is upon the admin, to know what they are doing, and it is definitely an advanced configration. But it can be useful in certain scenarios, that was my only point.
I will definitely appreciate any solution you will implement, as long as it restores the ability to sync calendars for private forums 
(preferably with the ability to connect multiple calendar apps to the same events calendar for the same user).