SongBeamer Forum

Verfasst: **Mo Nov 14, 2022 6:54 pm**

Hallo zusammen,

wie versprochen teile ich gerne meinen aktuellen Stand der Hilfskripte die wir verwenden um
a) Automatisiert unsere Liedersammlung nach ChurchTools zu laden
https://github.com/bensteUEM/ChurchTool ... tag/v1.0.0

b) Qualitätssicherung und automatische Uploadfunktionen speziell für Songbeamer Dateien durchzuführen.
https://github.com/bensteUEM/SongBeamerQS

Wer möchte (und Python versteht) kann sich gerne daran bedienen. Aktuell ist vor allem der Code zur Qualitätssicherung der Songbeamer Dateien spezifisch auf die dringendsten Bedarfe bei uns ausgerichtet. Auf bitten von @beamerteam, @kolibri52 und weiteren habe entschieden den Code in seiner aktuellen Form als CC-BY-SA 2.0 zu veröffentlichen und hoffe den in Zukunft noch deutlich zu verbessern. Ihr könnt den aktuellen Stand als erste "ALPHA" Test Version sehen.

WARNUNG - Wer nicht programmieren kann sollte die Finger davon lassen. Die Skripte können Massenänderungen durchführen und bei unsachgemäßer Verwendung sowohl eure lokale Liedersammlung als auch euer ChurchTools komplett durcheinanderwirbeln.
Generell empfehle ich dringend vorher Backups anzulegen!

Die OpenSource Lizenz - in Kurzfassung - Wer den Code unverändert nutzt darf das gerne ohne Gewährleistung kostenlos tun.
JEDER der daran auch nur eine einzige Zeile anpasst ist aber verpflichtet diese zeitnah auch mit der selben Lizenz zu veröffentlichen.
Vermutlich wird daraus jetzt kein ausführliches neues OpenSource Projekt, es wäre aber schön wenn wir es als gemeinsame Grundlage nutzen könnten und nicht jeder das Rad neu erfindet.

Das bedeutet konkret -> Wer programmieren kann und etwas ergänzt, meldet euch gerne damit kein Chaos entsteht sondern die Änderungen wieder Zusammengeführt werden können. Ich bin dabei offen für jegliche (auch strukturelle Verbesserung), solange das aktuelle feautreset beibehaltne wird.
Als Issue Backlog würde ich gerne weiterhin Github verwenden.

Verfasst: **So Dez 04, 2022 4:53 pm**

Nice. Besten Dank.
Kann man sicher gut brauchen.
Und man kann sich da einiges abschauen.

Verfasst: **Mo Jan 02, 2023 5:19 pm**

Hallo Benste,

vielen Dank dir für deine Arbeit. Sorry für die späte Rückmeldung.
Ich hatte mit dem Code im API-Repository noch Probleme mit dem CSRF-Token.
Wenn ich es so ausführe:

Code: Alles auswählen

api = ChurchToolsApi(domain)
api.get_ct_csrf_token()
api.file_upload('G:\Downloads\Absoluto guto3.sng','song_arrangement','376','Absoluto guto3.sng')

Dann kommt bei bei mir beim Upload der Fehlercode 401: "CSRF-Token invalid..."
Damit es bei mir funktioniert, muss ich in der Funktion get_ct_csrf_token den Token noch dem Header der aktuellen Session hinzufügen:
Also hab ich in get_ct_csrf_token() vor dem return noch folgende Zeile eingefügt:

Code: Alles auswählen

self.session.headers['csrf-token']=csrf_token

Kannst du meinen Fehler nachvollziehen? Ich wundere mich nur darüber, wie das bei dir funktioniert ohne diese Zeile.
Ich würde die Funktion get_ct_csrf_token() noch in die Init Funktion / Konstruktor reinpacken weil das gehört ja eigentlich zum Login, der ja bereits in der Init-Funktion aufgerufen wird.

Für das API-Repository hab ich schon drei Funktionen implementiert, die ich in deinem API-Repository hinzufügen würde, wenn in deinem Sinne:

get_eventId_NextEvent(self)

get_song_tags_all(self)

file_download(self, file_url: str, target_path: str)

Das will ich für unsere Gemeinde umsetzen (noch nicht fertig):

Upload von SNG-Dateien, wenn lokale Version neuer als die Version, welche online ist.

Download von SNG-Dateien, wenn online-Version noch nicht lokal verfügbar ist.

Download vom Songbeamer-Ablauf des nächsten Events (Ich hätte gerne den Songbeamer-Ablauf schon automatisch beim Systemstart im Download-Ordner des Technik-PCs vorort geladen)

Für diese Gemeindespezifische Logik wäre es sinnvoller, wenn ich ein extra Repository dafür erstelle - natürlich würde ich dann auf dein API-Repository als Referenz verweisen?

Verfasst: **Mo Jan 02, 2023 7:21 pm**

Hi, das klingt ja gut wenn es bei dir einigermaßen läuft - hast du einen Github Account und kannst den Code dort als merge request zur Verfügung stellen? Das würde es einfacher machen dich als Co-Author des Moduls auszuweisen. Zu den einzelnen Themen ... (zum Fehler in einem separatem Post)
Schick mir am besten neben Zugang zu deinem Code einfach mal einen Vorschlag wie ich dich / deine Kirchengemeinde entsprechend als Author mit in der Readme oder so benennen kann.

Ich habe mal einzelne Issues für die Themen von dir angelegt, am einfachsten wäre es glaube ich die Diskussion darin fortzusetzen, zur Not auch in Deutsch ... wäre auf jeden Fall übersichtlicher als hier im Forum technische Details auszutauschen.

get_eventId_NextEvent(self)
https://github.com/bensteUEM/ChurchToolsAPI/issues/3
Hier hätte ich ggf. noch einen Vorschlag, kenne deinen Code aber ja noch nicht.

file_download(self, file_url: str, target_path: str)
https://github.com/bensteUEM/ChurchToolsAPI/issues/4
> Hier wäre super wenn du den Code mal teilst, ich kann mir noch nicht genau vorstellen was die Funktion implementiert. Aber du hast ja sicher auch DocStrings ergänzt...

file_download(self, file_url: str, target_path: str)
https://github.com/bensteUEM/ChurchToolsAPI/issues/5
Hier wäre wichtigt, das target_path optional ist bzw. zumindest ein default bekommt.
Außerdem macht es ggf. Sinn die Up und Downloadfunktion einheitlich zu gestalten.
Ich weiß es ist problematisch da Dateien den gleichen Namen haben können, bisher sind die upload und delete Funktionen aber über domain und ID sowie Namen identifziert, das würde ich gerne konsistent halten. Entweder wir nennen die Funktion anders oder wir passen sie einfach an?

Upload von SNG-Dateien, wenn lokale Version neuer als die Version, welche online ist.
https://github.com/bensteUEM/SongBeamerQS/issues/8
Wenn du einen sinnvollen Vorschlag für einen Comparator hinbekommst klingt das gut, ich hatte die Idee Verworfen - zu Gunsten der These das CT immer die aktuellste Version hat - weil ich auf Anhieb keinen Indikator hatte der qualitativ hochwertig angibt welche Datei "neuer" bzw. höherwertiger / besser ist. Ich wollte auf keinen Fall die Dateien vom PräsentationsPC automatisch übernehmen. Je nachdem ob das auf Basis des SNG Files oder reiner Metadaten passiert müsste man auch überlegen in welches der beiden Module es besser passt.

Bei uns nutzen wir aktuell immer die Downloadoption aus ChurchTools, diese lädt die SNGs immer in einem extra Ordner spezifisch in der neusten Version mit herunter damit ist für uns hier aktuell kein Need für Download und oder Vergleich für den Upload gewesen. Was ich aber machen wollte war ggf. das "Editor" Tag in den SNG Dateien dafür zu verweden. Automatische Überarbeitungen bekommen bei mir immer den Skriptnamen mit Datum.
Aber ist ein Skriptname immer neuer als bsp. 6.00f ... selbst wenn man hier eine Version/Datumsliste mitpflegen würde könnte ja auch jemand mit einer alten Songbeamer Version eine neuere Datei als der letzte Skript Durchlauf erzeugen...

Download von SNG-Dateien, wenn online-Version noch nicht lokal verfügbar ist.
https://github.com/bensteUEM/SongBeamerQS/issues/7
Hatte ich auch vor nur noch nicht angefangen ... bist du da Zeitnah dran oder soll ich? Die Funktion zu validieren welche existieren gibt es glaube ich schon - bzw. in den Debugging Teilen des SNG Projektes gibt es Pandas Dataframes die hier zumindest einen Log Eintrag für den Fall generieren...
Die Funktion würde ich aber eher im Songbeamer Projekt als in der ChurchTools API sehen.

Download vom Songbeamer-Ablauf des nächsten Events (Ich hätte gerne den Songbeamer-Ablauf schon automatisch beim Systemstart im Download-Ordner des Technik-PCs vorort geladen)
https://github.com/bensteUEM/SongBeamerQS/issues/9
Überlegt hatte ich es auch schon ... dachte mir nur die Techniker sollten sich zumindest einmal den Ablauf angucken müssen

Außerdem sehe ich hier das Risiko, dass sollte das Skript und ich einmal ausfallen langfristig ggf. das wissen bei unseren Freiwilligen verloren geht wie man denn an den Ablauf kommt.
Hast du mal über die WebDeveloper Tools geprüft welche Funktion dazu Online für das ZIP Paket verwendet wird? würde glaube ich eher die als einzelne Downloads mit erkennen des nächsten Events verwenden ...
Wenn du es codest kann ich es gerne mit ins Programm übernehmen, muss es ja nicht verwenden...

Verfasst: **Mo Jan 02, 2023 7:44 pm**

Also wenn du nur genau den Code nutzt den du unten beschreibst müsste es eigentlich gehen. Hast du mal die Test Cases ausgeführt?

Meine Tests initialisiere ich ja auch nur mit

Code: Alles auswählen

self.api = ChurchToolsApi(domain)

Die beiden Cases laufen bei mir quasi ohne nennenswerte Probleme

Code: Alles auswählen
```
test_get_ct_csrf_token() 
```
ohne Fehler

Code: Alles auswählen
```
test_file_upload_replace_delete()
```
Dabei bekomme ich zwar eine SSL Warnung - weil unsachgemäß gerwendet, der Vorgang selber funktioniert aber.
Achtung - hier brauchst du vermutlich andere IDs zum testen ...

Wenn du den Code 1:1 so verwendest wundert mich wie du auf den Fehlercode kommst.
Ich hatte das Problem mit den alten CSRF Tokens glaube ich am Anfang auch mal mit dem Legacy Login - der Code müsste ja aber wenn du ihn nicht weiter angepasst hast ganz normal deinen Login-Token (nicht zu verwechseln mit CSRF Token für legacy API) und nicht den Ajax legacy login verwenden.

Nutzt du ebenfalls den neueren REST Login

Code: Alles auswählen

login_ct_rest_api(ct_token)

der kann für beide APIs verwendet werden oder meldest du dich mit user/passwort an? also über

Code: Alles auswählen

login_ct_ajax_api(self, user=list(users.keys())[0], pswd=""):

Den AJAX Login müsste ich glaube ich sogar entfernen können, soweit ich mich erinnere funktionieren die AJAX API Aufrufe auch über die neueren Login Token. Die Fehlermeldung sieht verdächtig nach der Verwendung der Legacy Login Option aus...die wäre eigentlich veraltet ... Falls ja tendiere ich eher zur Anpassung der Dokumentation als zur Abfrage eines CSRF Tokens der für die meisten API Aufrufe glaube ich nicht benötigt wird.

Wenn du mir das kurz noch bestätigst und es wichtig findest könnte ich aber dein

Code: Alles auswählen

self.session.headers['csrf-token']=csrf_token

in der

Code: Alles auswählen

get_ct_csrf_token(self):

mit aufnehmen - dann würde es immerhin nach ausführen der Funktion da existieren - ist das denn der Ort wo der Parameter hin muss?

Verfasst: **Mo Jan 02, 2023 10:45 pm**

Okay dann mach ich doch einen Fork in Github. Hab gesehen die Forks sind scheinbar in Github doch üblich / notwendig um einen Pull Request zu stellen.

Ja, beim Ausführen der Testfunktionen bin ich auch zu keinem anderen Ergebnis gekommen. Die Tests sind an der gleichen Stelle in der Upload-Funktion fehlgeschlagen mit gleichem Status-Code.

Also ich hatte viel ausprobiert bis ich auf die Lösung kam. Unter anderem auch den Weg über die alte Ajax-API.
Deshalb hab ich gerade extra nochmal dein frisches Repository verwendet und nur die Secure-Dateien ausgetauscht,
um sicher zu sein, dass das wirklich der Grund war.
Ich vermute, das wir möglicherweise verschiedene Churchtools-Versionen nutzen und meine Version (ChurchTools 3.93.2: 31922) da restriktiver ist.

Ich mache den Login wie du - also mit login_ct_rest_api(ct_token)
Wenn ich in der main.py meine Zeile mit api.file_upload() ergänze wie hier

Code: Alles auswählen

    api = ChurchToolsApi(domain_temp)
    api.login_ct_rest_api(ct_token)
    api.file_upload('G:\Downloads\Absoluto guto3.sng','song_arrangement','376','Absoluto guto3.sng')

Dann kommt in der Funktion file_upload() definitv der Fehler 401:
Bild

Ich kann auch direkt im Main-Script meine Zeile ergänzen, dann geht es auch - die Datei wird dann korrekt hochgeladen z.B. so (siehe 3. Zeile):

Code: Alles auswählen

    api = ChurchToolsApi(domain_temp)
    api.login_ct_rest_api(ct_token)
    api.session.headers['csrf-token']=api.get_ct_csrf_token()
    api.file_upload('G:\Downloads\Absoluto guto3.sng','song_arrangement','376','Absoluto guto3.sng')

Du kannst das in der API in der get_ct_csrf_token(self) einzubauen oder stattdessen für alle Abfragen auch gleich in die __init__(self, domain) einfügen.
Die __init__(self,domain) würde dann so aussehen (letzte Zeile hinzugefügt):

Code: Alles auswählen

        self.session = None
        self.domain = domain

        from secure.secrets import ct_token
        self.login_ct_rest_api(ct_token)
        self.session.headers['csrf-token'] = self.get_ct_csrf_token()

Verfasst: **Di Jan 03, 2023 7:02 am**

Wir nutzen auch die ChurchTools 3.93.2: 31922, daran wird es also wohl nicht liegen. Die 376 Song ID exisitert auf eurem System oder? Unseres läuft aber auf der KRZ.tools Instanz bisher habe ich zwar kaum Unterschiede zur Church.Tools Instanz gefunden könnte man aber mal prüfen.

Wenn du magst kannst du mir mal einen Nutzer mit entsprechend eingeschränkten Rechten auf eurem System einrichten, dann kann och mal gucken ob es wirklich am System liegt... kannst mir URL und Login Token einfach per PN schicken, ich würde dann die selbe SongID nutzen.

Das einzige was mir bei deinem Pfad noch auffällt ist, dass du Windows nutzt und ich Linux... hoffe aber mal das es nicht daran liegt.verschiedene Python Versionen sollten hoffentlich keinen großen Unterschied machen...

Verfasst: **Do Jan 05, 2023 9:11 pm**

Nur zur Info für alle anderen - kolibri implementiert gerade seine zusätzlichen Funktionen und der "Fehler" ist auch schon behoben.
Auf meinem System war die CSRF Validierung aus, jetzt funktioniert es auch eingeschaltet ...

Alle offenen Wünsche und Ideen gerne hier:
https://github.com/bensteUEM/ChurchToolsAPI/issues

SongBeamer Forum

ChurchTools / Songbeamer Python Skripte

ChurchTools / Songbeamer Python Skripte

Re: ChurchTools / Songbeamer Python Skripte

Re: ChurchTools / Songbeamer Python Skripte

Re: ChurchTools / Songbeamer Python Skripte

Re: ChurchTools / Songbeamer Python Skripte

Re: ChurchTools / Songbeamer Python Skripte

Re: ChurchTools / Songbeamer Python Skripte

Re: ChurchTools / Songbeamer Python Skripte