Add Password Protection

[Shark]

We use links to the Radar for pre-application marketing, so theoretically, anyone can view it even if they didn't apply or didn't get accepted.

There should be a global password (per Radar instance) that users must enter before they can access anything.

But we have to also consider the cons of access protection: it will be harder to access the content, which could lead to decreased usage. To account for this, the password should be the same for all participants and be simple (for example, just one word).

[danrocha]

Agree. It is a simple app, so let's keep auth also as simple as possible.

I can take a shot at it in the next days if it's ok. I'll sketch some flows in Figma and we can try to implement it by October's onboarding phase.

[Maxscha]

I like the idea, and I think a simple password should be sufficient for now.
But if we want to password protect it, we would also need to make the repo here private, or seperate at least the content into a private repo.

[danrocha]

Indeed. You can still see all the links and everything just by coming to the repo. Maybe for v2.0 of the auth system we could consider moving the content to a CMS. Right now, a simple initial block should suffice and keep most unwanted people away. We could also, initially, remove the Github link from the radar page and only show it to authenticated users.

…

On 15. Sep 2020, 09:34 +0200, Maximilian Schall ***@***.***>, wrote: I like the idea, and I think a simple password should be sufficient for now. But if we want to password protect it, we would also need to make the repo here private, or seperate at least the content into a private repo. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Maxscha]

Hmm, what I liked about the radar is the easyness to get into it and change it quickly. A CMS would bring us into the same direction as with the general Techlabs website.

I mean we can basically move into two directions:

• Either we keep it open as it is, and have it quickly and centralised changeable, but with the risk that we have malicious introducers
• Or we try to secure it, and loss the benefits, but make it more secure.

[danrocha]

If we look at both scenarios:

1. Leave it open

• content update, while easy for us, is not easy for less technical people/content update still required a build process
• Were there any problems last semester?
• In case we have unwanted access, what are the consequences? (manegeable?)
• Could we password protect resources, instead of the radar (like Zoom access, or Google Docs, or Typeforms), and only publish the passwords on Slack for the students?

2. Password protect

• Extra layer of complexity, more systems to orchestrate, makes adaptation and usage by other cities more complicated
• We could go for simpler CMSs than Contentful (like Storyblok, for example)
• Would open up content update to the less technical members

For me, both options are fine. We could do a test-run with a CMS and password protection and see how that goes, as we can always revert back to using static files. Or we could leave as it is and move the security layer to where actually critical.