search

hitobito / hitobito_sbv

Wagon for https://github.com/hitobito/hitobito for Schweizer Blasmusikverband
Other
2 stars 2 forks source link

Access-Control-Allow-Origin: * #75

Closed betsim closed 3 years ago

betsim commented 4 years ago

Ich verstehe die Problematik, weshalb Access-Control-Allow-Origin: * in Kombination mit der User-API keine gute Idee ist. Ich sehe allerdings auch, dass aus Anwender-Sicht es sehr oft keine Alternative ist, die API-Calls serverseitig zu lösen, weil schlicht das Wissen fehlt. JavaScript ist m.E. aktuell nunmal die Sprache bei Webapplikationen. Im SBV ist es zudem eine zwingende Anforderung, dass z.B. Kurse aus hitobito einfach auf den Websites der Kantonal- oder Regionalverbände angezeigt werden können.

Daher meine Frage @olibrian : kann die User-API für den SBV mit wenig Aufwand deaktiviert und dafür Access-Control-Allow-Origin: * aktiviert werden oder bedarf das eines grösseren Eingriffs?

Originally posted by @betsim in https://github.com/hitobito/hitobito/issues/961#issuecomment-666532933

carlobeltrame commented 4 years ago

Ich hatte die Änderung für Service Tokens in https://github.com/hitobito/hitobito/issues/961#issuecomment-672011636 ja schon auf 6h geschätzt. Daran interessiert sind auch noch andere hitobito-Community-Mitglieder, nach meinem letzten Stand explizit Cevi und PBS. Den Aufwand dafür könnte man sich also sogar aufteilen.

Möchtet ihr beim SBV denn explizit die User-API benutzen, passen die Service Tokens also nicht für euren Use Case? Es gibt durchaus berechtigte Use Cases dafür, aber viele API-Anbindungen könnn auch via Service Tokens funktionieren. Oder braucht ihr eher einfach eine kurzfristige Lösung um übermorgen mit der Implementation von externen Tools zu beginnen?

Aus Sicht der anderen beiden erwähnten Organisationen [1] [2] soll die User-API mittelfristig deaktiviert werden, um zu vermeiden dass ein Benutzer seine hitobito-Credentials an eine externe Applikation geben muss. Eine zukünftige Alternative wäre gegebenenfalls via OAuth, siehe hitobito/hitobito#1040, wo sich gerade erst noch ein weiterer hitobito-Benutzer dafür interessierte.

Aktuell versuchen wir, die Security bei hitobito systematisch zu verbessern. Die Einführung von Access-Control-Allow-Origin: * wäre aus meiner Sicht in diesem Hinblick ein Rückschritt, und würde es zudem erschweren, die User-API langsam zu Gunsten von sichereren API-Optionen zu entfernen.

betsim commented 4 years ago

Möchtet ihr beim SBV denn explizit die User-API benutzen, passen die Service Tokens also nicht für euren Use Case? Es gibt durchaus berechtigte Use Cases dafür, aber viele API-Anbindungen könnn auch via Service Tokens funktionieren. Oder braucht ihr eher einfach eine kurzfristige Lösung um übermorgen mit der Implementation von externen Tools zu beginnen?

Nein, wir sind absolut einverstanden damit, dass die User-API deaktiviert werden soll. Vielleicht verstehe ich das Konzept der Service-Tokens nicht (btw: wo erstelle ich einen Service-Token❓), aber nach meinem Verständnis einer API spielt es für die Frage von Access-Control-Allow-Origin keine Rolle, wie authentifiziert (d.h. ob mittel User-Credentials oder mittels Service-Token) wird.

Ich möchte einfach so schnell wie möglich unseren Mitgliedern JS-Snippets zur Verfügung stellen können, die sie in ihren Websites einbinden können, um Kurse und Anlässe anzuzeigen – wir möchten unsere Mitglieder so rasch wie möglich dazu bringen, Kurse und Anlässe nur noch in hitobito zu erfassen, um dessen Akzeptanz weiter zu fördern.

Es ist mir absolut bewusst, dass Access-Control-Allow-Origin: * ein Schritt in die falsche Richtung ist (den man später sicher wieder korrigieren muss) – aber bis auf unbestimmte Zeit gar kein JS einsetzen zu können, ist auch keine Lösung, weil damit ein Teil von hitobito nicht genutzt werden kann. – Oder übersehe ich eine Möglichkeit, die API bereits jetzt einfach (d.h. ohne weitere Technologien wie z.B. php) in eine Website einzubinden?

carlobeltrame commented 4 years ago

Service Tokens können von Personen mit ausreichend Schreibrechten auf jeder Gruppe erstellt werden, im Tab API-Keys. Für einen API-Key (= Service Token) kann man auswählen welche Berechtigungen er haben soll, die Berechtigungen sind aber immer auf die Gruppe limitiert.

Auch bei Service Tokens haben wir bisher noch keine CORS-Headers, aber wie gesagt wäre dort der aufteilbare Aufwand das einzuführen 6 Stunden.

Falls euch die Service Tokens nicht reichen, sondern ihr persönlichen API-Access braucht, wäre es dennoch nicht zielführend, den ACAO: * Header einzuführen. Sobald nämlich die "alte" persönliche API durch API-Access via OAuth abgelöst wird, würden eure JS-Snippets ungültig, und alle externen Applikationen welche diese verwenden müssten wieder umgebaut werden.

Wenn das alles kein Argument für euch ist könntet ihr immer noch einen "API CORS Proxy" (z.B. [1] oder [2]) irgendwo selber laufen lassen, an welchen man mit JS Anfragen senden kann und welcher dann serverseitig die Anfrage im Namen des Browsers tätigt und Response inklusive CORS-Headers zurückliefert. Ich kann das aus Software-Architektur- und Security-Sicht absolut nicht empfehlen, aber technisch gesehen ist es eine Möglichkeit.