OpenAtlas

I was thinking about the authentication issue. The API is either accessible (public) or not and authentication via frontend gets tricky because requests are sent from some web client.

• For testing we can use the Origins project, it has a small data set (so less likely performance issues) and the API is already set public.
• For concluded projects it shouldn't be a big issue, e.g. the demo versions MEDCON and DPP are already cleaned up data wise and open anyway (nevertheless we will ask for permission).
• THANADOS is a case where we have a public frontend but not all data should be accessible BUT because the THANADOS frontend uses Flask we could implement an IP restriction (#1377)

After a meeting with Bernhard we decided following adaptions:

• Check if tokens can be copied if transferred via a web request

• Token generation
  • Only for admins (at least for now)
  • Move form to admin area
  • Table select for user_id
  • Save current user in an additional table field (e.g. creator_user_id or similar)
  • Change token input field
    • Remove from insert
    • Show in grey text area after creation but keep the handy copy button

• Token list view
  • Add delete column (with JavaScript confirm)
  • Add creator column
  • Sort and mark active tokens that are:
    • User has to exist and be active
    • Valid to date has to be in future
    • Not revoked

• Check if tokens can be copied if transferred via a web request

I've tested it and looked into it further; the Authorization header does not appear in the browsers' developer tools. Clearly, there are ways to get those tokens, but the effort would be higher than to crawl the existing presentation site with a script. And since we host open data projects and the access token from a presentation page is strictly read-only, I believe this security measure is adequate.