Kalender REST API Berechtigungsproblem seit v3.103.1

davidschilling

@aschild
Mir fällt aktuell nicht ein was wir an dieser Stelle geändert haben sollen.
Du könntest ja mal testen dich mit dem User im Browser einzugeben und die Api über die Browser URL Zeile aufzurufen. Passiert dann das gleiche?

aschild

@davidschilling Habe es nun auch versucht.
Wenn der User via benutername+PW angemeldet ist, dann funktioniert es, der User hat Kalenderzugriff

Dann kann ich auch via

curl -X 'GET' \
  'https://tools.ref-nidau.ch/api/persons/1551/logintoken' \
  -H 'accept: application/json' das Logintoken abrufen.

Aber wenn ich dann das zurück gegebene logintoken angebe, dann gibt es mir hier nur 3 Kalender aus, und das sind die die öffentlich einsehbar sind...

Scheint also ein Problem mit der Token Validierung zu sein

curl -X 'GET' \
  'https://tools.ref-nidau.ch/api/calendars' \
  -H 'accept: application/json' \
  -H 'Authorization: login-token-aus-obiger-rest-abfrage'

{
  "data": [
    {
      "id": 2,
      "name": "Gottesdienste",
      "nameTranslated": "Gottesdienste",
      "sortKey": 10,
      "color": "#f83a22",
      "isPublic": true,
      "isPrivate": false,
      "randomUrl": "xxxxxxxxxxxxx",
      "iCalSourceUrl": "",
      "campusId": null,
      "eventTemplateId": null,
      "meta": {
        "modifiedDate": "2015-02-13T23:00:00Z",
        "modifiedPid": -1
      }
    },
    {
      "id": 63,
      "name": "KUW",
      "nameTranslated": "KUW",
      "sortKey": 78,
      "color": "#92e1c0",
      "isPublic": true,
      "isPrivate": false,
      "randomUrl": "xxxxxxxxxxx",
      "iCalSourceUrl": "xxxxxxxxxxxxxxxxxxx",
      "campusId": null,
      "eventTemplateId": null,
      "meta": {
        "modifiedDate": "2023-11-23T23:09:30Z",
        "modifiedPid": 1
      }
    },
    {
      "id": 64,
      "name": "Anlässe & GD's auf Webseite",
      "nameTranslated": "Anlässe & GD's auf Webseite",
      "sortKey": 1500,
      "color": "#9fe1e7",
      "isPublic": true,
      "isPrivate": false,
      "randomUrl": "xxxxxxxxxxxx",
      "iCalSourceUrl": "xxxxxxx",
      "campusId": null,
      "eventTemplateId": null,
      "meta": {
        "modifiedDate": "2023-11-23T23:09:30Z",
        "modifiedPid": 1
      }
    }
  ],
  "meta": {
    "count": 3
  }
}

aschild

@aschild Vorher waren wir auf v3.102.0 und dann direkt auf die v3.103.1

Ev. etwas in dem Zusammenhang

Changelog

Die Endpunkte GET /calendars und GET /calendars/<id>/appointments können auch vom unauthentifizierten Benutzer aufgerufen werden.

Ich habe noch mit einem anderen user+token versucht, geht auch nicht....

aschild

@davidschilling Es scheint dass das Token seit dem Update nicht mehr gültig ist.
Bei allen anderen API aufrufen kommt die Meldung

{"message":"Session expired!","translatedMessage":"Die Session ist abgelaufen, bitte logge dich erneut ein.","messageKey":"exception.unauthorized","args":[],"errors":[]}

Wie kann ich ein neues Token erstellen lassen? Den delete API Endpunkt gibt es da ja noch nicht.
Nach dem setzten eines neuen PW hat sich auch das Token verändert, funktioniert aber unverändert nicht.

Supportticket ist erstellt.

aschild

@davidschilling So, nun haben wir das Problem isolieren können, nun brauche ich noch einen Tipp zur Lösung.

Wir verwenden eure JS library dazu, unter nodejs
Mit dem Code hier;

const myCT= new ChurchToolsClient();
myCT.setCookieJar(axiosCookieJarSupport.wrapper, new tough.CookieJar());
myCT.setBaseUrl(config.site_url);
myCT.setUnauthorizedInterceptor(config.auth_token);
activateLogging();

Verhalten vor v3.103.1 bein Aufruf von GET /calendars/<id>/appointments

Die JS library senden einen request ohne Login Token
Rückgabe eines 401 codes, da nur für angemeldete User verwendbar
Die JS library macht dann ein Retry mit dem login token und dann kommen die Einträge

Verhalten ab v3.103.1 bein Aufruf von GET /calendars/<id>/appointments

Die JS library senden einen request ohne Login Token
Rückgabe eines 403 codes, da keine Berechtigung für die privaten Kalender existiert
Die JS library macht keinen Retry, da code 403 und nicht 401

Nun stellt sich mir die frage ich ich der Library sagen kann, dass immer das Logintoken mitgesendet werden soll?

davidschilling

@aschild ah ich hab eine Idee. Versuche mal den ersten Request nicht auf die Termin Api zu machen sondern auf /api/whoami/only_allow_authenticated?only_allow_authenticated=true.
Die Termin Api braucht nicht mehr unbedingt einen Login. Es werden dort jetzt im nicht eingeloggten Zustand die Rechte des öffentlichen Users benutzt. Das könnte mit dem Problem zusammenhängen.
Wenn du den ersten Request auf den whoami call gemacht hast müsstest du danach eine eingeloggte Session haben.

aschild

@davidschilling Danke, ja, so funktioniert es.

const myCT= new ChurchToolsClient();
myCT.setCookieJar(axiosCookieJarSupport.wrapper, new tough.CookieJar());
myCT.setBaseUrl(config.site_url);
myCT.setUnauthorizedInterceptor(config.auth_token);
activateLogging();

/** Force login */
function preLogin() {
    myCT.get('/whoami?only_allow_authenticated=true').then(whoAmI => {
        // console.dir(whoAmI);
        // console.log(`Hello ${whoAmI.firstName} ${whoAmI.lastName}!`);
    });
    }
preLogin();

Und dann die normalen API calls und die gehen direkt mit dem Logintoken durch.
Wäre sicher für andere hilfreich wenn das im github repo auch so dokumentiert ist.

davidschilling

@aschild ja, bzw. oder das das gar nicht nötig ist.

thommyb

@aschild Ist vielleicht eine blöde Frage, aber warum gibt es denn diese Retry-Logik? Warum schickst du nicht gleich/immer den Login-Token mit?

aschild

@thommyb sagte in Kalender REST API Berechtigungsproblem seit v3.103.1:

@aschild Ist vielleicht eine blöde Frage, aber warum gibt es denn diese Retry-Logik? Warum schickst du nicht gleich/immer den Login-Token mit?

Wenn du mir sagst wie man das mit eurem JS client macht, dann her mit den Infos
In den anderen Clients (php etc.) wird das lgin token defaultmässig immer mitgesendet