• Aktuell
    • Tags
    • Beliebt
    • Benutzer
    • Gruppen
    • Suche
    • Registrieren
    • Anmelden

    Tokens bei AJAX API

    ChurchTools Schnittstellen
    6
    12
    772
    Lade mehr Beiträge
    • Älteste zuerst
    • Neuste zuerst
    • Meiste Stimmen
    Antworten
    • In einem neuen Thema antworten
    Anmelden zum Antworten
    Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
    • jziegelerJ
      jziegeler ChurchToolsMitarbeiter @MichaelM
      zuletzt editiert von

      @michaelm schau mal hier:
      https://forum.church.tools/topic/7027/resourcenbelegung-via-php-curl_exec-abfragen/8 Hans-Helge hat es eigentlich ganz gut erklärt

      1 Antwort Letzte Antwort Antworten Zitieren 0
      • M
        MichaelM
        zuletzt editiert von Andy

        Danke, das hilft.
        Aber zum CSRF-Token, da schreibt er ja auch: "Du musst diesen CSRF Token abfragen und mit den POSTs bei der alten API mitschicken."
        Ich schicke es nicht mit (siehe oben) und die Abfrage der Fakten funktioniert trotzdem. Ich hätte erwartet, dass die Abfrage in dieser Form fehl schlagen muss.

        M 1 Antwort Letzte Antwort Antworten Zitieren 0
        • M
          MarkusP @MichaelM
          zuletzt editiert von

          @michaelm
          Das kann ich auch bestätigen. Ich programmiere seit ein paar Tagen auch an einem Programm und der CSRF Token ist egal. Auch über Postman funktioniert das ohne Problem ohne den CSRF Token.

          Zum Login Token:

          1. Über API V1 mit Token und ID anmelden und Cookie speichern (login/ajax;func=loginWithToken; token; id)
          2. Über API V2 bei einem Call (z.B. api/whoami) den Token im Header mitgeben (Authorization: Login <Token>) und Cookie speichern (falls du mit der API V1 weiterarbeiten möchtest)

          Für die API V2 muss man sich nicht speziell einloggen, da reicht es den Token immer im Header mit zu geben. Dann muss man auch nicht mit Cookie rumhantieren.

          Ich sehe aber im Login Token keine höhere Sicherheit, es macht es nur bei API V2 einfacher, weil du dich nicht einloggen bzw. dauernd ein Cookie mitschleppen musst.

          B 1 Antwort Letzte Antwort Antworten Zitieren 0
          • B
            bwl21 @MarkusP
            zuletzt editiert von

            @markusp sagte in Tokens bei AJAX API:

            Für die API V2 muss man sich nicht speziell einloggen, da reicht es den Token immer im Header mit zu geben. Dann muss man auch nicht mit Cookie rumhantieren.

            dann macht er aber mit jedem Aufruf eine neue Session auf. Du siehst das dann im Frontend, dass der Benutzer x mal eingeloggt ist.

            M 1 Antwort Letzte Antwort Antworten Zitieren 0
            • M
              MarkusP @bwl21
              zuletzt editiert von

              @bwl21
              Ich glaube da kommt es darauf an, in welchem Umfang man die Schnittstelle benötigt. Wenn er einmal die Woche die Fakten ausließt (nur ein Call), dann wäre dies nicht so schlimm.

              In meinem Fall verwende ich nach dem Login auch den Cookie, da ich einige Aufrufe durchführe.

              Aber ehrlich gesagt wusste ich das gar nicht. Dann wäre es gut, wenn das auf der API Seite im Punkt Authentication auch noch ergänzt wird. Da ließt man es so, dass beides gute Lösungen sind.

              1 Antwort Letzte Antwort Antworten Zitieren 0
              • hbuergerH
                hbuerger ChurchToolsMitarbeiter
                zuletzt editiert von

                Um hier etwas Klarheit rein zu bringen.

                Authorization

                Egal ob AJAX API (v1) oder REST API (v2) in beiden Fällen kann man sich mit Username/Passwort einloggen ODER den Login Token mitschicken.

                Authorization: Login <token> funktioniert mit beiden APIs.

                Wichtig: In beiden Fällen bekommt man ein Cookie zurück und dieses Cookie sollte man mitschicken in folge Requests. Wenn das Cookie fehlt und man immer fröhlich den LoginToken mitschickt, dann wird für jeden Request eine neue Session erstellt.

                Das ist nicht nur doof, weil es auf der Startseite angezeigt wird, sondern hat auch Performance Gründe. Bei einer neuen Session werden die Rechte für den Nutzer berechnet. D.h. mit Cookie ist der Request auch schneller.

                Hint: Man kann den LoginToken trotzdem mitschicken zusätzlich zum Cookie. Wenn die Session im Cookie noch aktiv ist, dann ist alles supi. Wenn es keine Session gibt, dann fällt CT zurück und nutzt den Login Token.

                CSRF Token

                Der Token sollte immer vom System geprüft werden, wenn ein Formular abgeschickt wird, dass mit POST verschickt wird.

                Ich investigiere gerade ob hier ein Bug vorliegt. Mit welchem Content Type verschickt ihr denn den Request?

                ChurchTools Mitarbeiter – Trainer – Supporter – Academy

                M 1 Antwort Letzte Antwort Antworten Zitieren 0
                • M
                  MichaelM
                  zuletzt editiert von MichaelM

                  Danke schonmal für eure Antworten.

                  @hbuerger
                  Ich hatte bisher überhaupt kein Content Type angegeben und es funktionierte (s.o).
                  Wenn ich einen Header mit application/x-www-form-urlencoded übergebe, bekomme ich die Meldung "'CSRF-Token is invalid'". Wenn ich dann auch noch das CSRF-Token übergebe, funktioniert die Abfrage wieder.

                  # Header mit Content-Type aber ohne CSRF-Token --> Fehler
                  headers = { 'Content-Type': 'application/x-www-form-urlencoded',
                            # 'CSRF-Token': csrf_token 
                          }
                  response = session.post('https://mghh.church.tools/?q=churchservice/ajax&func=getAllFacts', headers=headers)
                  

                  Gleiches Spiel im Postman: Sobald ich den Content-Type mit übergebe, kommt die Fehlermeldung. Ohne Content-Type ist kein CSRF-Token notwendig.

                  1 Antwort Letzte Antwort Antworten Zitieren 0
                  • M
                    MarkusP @hbuerger
                    zuletzt editiert von

                    @hbuerger sagte in Tokens bei AJAX API:

                    Authorization: Login <token> funktioniert mit beiden APIs.

                    Wenn ich das bei der AJAX API mache (func: getPersonById), dann kommt aber beim ersten Aufruf eine Fehlermeldung (message: Parameter func not defined) und beim zweiten Mal klappt es dann, weil ein Cookie vorliegt. Test lief über Postman.

                    Mit welchem Content Type verschickt ihr denn den Request?

                    Beim Postman habe ich für getPersonById den Type multipart/form-data und für f_group den Type application/json verwendet. Beides hat ohne CSRF-Token geklappt
                    Ich hatte irgendwo gelesen, dass man application/x-www-form-urlencoded verwenden soll, aber nach kurzen Tests ist mir aufgefallen, dass man bei application/json den CSRF-Token nicht benötigt.

                    1 Antwort Letzte Antwort Antworten Zitieren 0
                    • hbuergerH
                      hbuerger ChurchToolsMitarbeiter
                      zuletzt editiert von

                      @michaelm sagte in Tokens bei AJAX API:

                      Ich hatte bisher überhaupt kein Content Type angegeben und es funktionierte (s.o).

                      Wenn du keinen Content-Type explizit angegeben hast, dann wird es vermutlich als text/plain verschickt. Das ist auch kein Problem.

                      Ich habe zudem einen Fehler gefunden, der mit v3.72.1 (die kommt in den nächsten Tagen) gefixt ist. Ab dann wird der Token für application/x-www-form-urlencoded und multipart/form-data erzwungen. Das sind die zwei Content Types, die mit Formularen genutzt werden in ChurchTools.

                      @markusp sagte in Tokens bei AJAX API:

                      Wenn ich das bei der AJAX API mache (func: getPersonById), dann kommt aber beim ersten Aufruf eine Fehlermeldung (message: Parameter func not defined) und beim zweiten Mal klappt es dann, weil ein Cookie vorliegt. Test lief über Postman.

                      func: musst du immer mit geben. Das ist ja der Methoden Aufruf, das hat nichts mit dem Login Token zu tun. func schickst du ja als Content mit. Den Login Token schickst du als Header mit.

                      ChurchTools Mitarbeiter – Trainer – Supporter – Academy

                      M 1 Antwort Letzte Antwort Antworten Zitieren 0
                      • M
                        MarkusP @hbuerger
                        zuletzt editiert von

                        @hbuerger sagte in Tokens bei AJAX API:

                        Ich habe zudem einen Fehler gefunden, der mit v3.72.1 (die kommt in den nächsten Tagen) gefixt ist. Ab dann wird der Token für application/x-www-form-urlencoded und multipart/form-data erzwungen. Das sind die zwei Content Types, die mit Formularen genutzt werden in ChurchTools.

                        Und wie sieht es mit application/json aus? Sollte es nicht bei allen Content Types erzwungen werden?

                        func: musst du immer mit geben. Das ist ja der Methoden Aufruf, das hat nichts mit dem Login Token zu tun. func schickst du ja als Content mit. Den Login Token schickst du als Header mit.

                        Das mache ich ja. Zwischen dem ersten und zweiten Aufruf mache ich keine Änderung, außer dass Postman automatisch das Cookie hinzufügt.

                        fbecec2f-d78b-4995-b97d-9a33e98d5ddf-image.png

                        davidschillingD 1 Antwort Letzte Antwort Antworten Zitieren 0
                        • davidschillingD
                          davidschilling ChurchToolsMitarbeiter @MarkusP
                          zuletzt editiert von

                          @markusp für application/json ist es nicht notwendig.

                          CSRF ist eine Sicherheitslücke die über Formulare in Browsern passieren kann. Wenn du einen ajax request im browser machst kannst du keinen csrf ausnutzen.

                          1 Antwort Letzte Antwort Antworten Zitieren 0
                          • Erster Beitrag
                            Letzter Beitrag