Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement ICS/RSS Restrictions #733

Open
CHTJonas opened this issue Oct 18, 2019 · 1 comment

Comments

@CHTJonas
Copy link
Member

@CHTJonas CHTJonas commented Oct 18, 2019

In response to my RFC from Monday, @hoyes made the following comment:

Re API authentication, we should maybe consider what to do for API endpoints that support the ICS or RSS formats (i.e. vacancy and diary feeds) where authentication doesn’t make sense

I think a sensible approach for the Diary iCal endpoints may be to restrict them so that shows are only returned in the range of today's date ± 4 weeks? This way people can still use it to 'plan' which shows they might want to see whilst also preventing others from scraping mass data programatically (e.g. via https://www.camdram.net/diary.ics?end=2021-01-01). It might also be an idea to remove the whole-diary iCal endpoint in favour of the individual society/venue iCal endpoints? This would further limit excessive scraping.

Personally, I'm tempted to say that the iCal/RSS feeds on the vacancies section are okay to leave as they are. There is personal information in there (contact details, for example) but I can't really think of a good solution here. I suppose the ideal aim is to make the site as unattractive as possible for scrapers whilst still making ICS/RSS useful for people in their newsreaders and digital calendars. This may be a losing game...

@CHTJonas CHTJonas added this to To Do in API Changes/Deprecations via automation Oct 18, 2019
@GKFX

This comment has been minimized.

Copy link
Member

@GKFX GKFX commented Oct 19, 2019

± 4 weeks seems like an odd time period. I'd prefer to allow people to look indefinitely into the future since people could reasonably expect a whole-term view, and once you've allowed that there aren't many shows published >>8 weeks in advance so there is little point in restricting access to the future at all. On past shows though we could easily cut off at 20 or even 14 days for unauthenticated users without anyone really noticing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2 participants
You can’t perform that action at this time.