Blog-Artikel Scripte migrieren nach #Codeberg

Ich hatte es schon angekündigt, dass ich die Scipte der vergangenen Artikel in einer Git-System hosten möchte, damit es etwas strukturierter wird. Ich habe mich für Codeberg entschieden.

Einleitung

Codeberg basiert auf gitea und wird von einem Berliner Verein zur Verfügung gestellt und es ist schnell meine erste Wahl geworden. Die Funktionen sind umfangreich, ausgereift und es arbeitet, wie Plume, mit Common Markdown.

Ich werde aber nicht die bisherigen Scripte 1:1 so übernehmen, wie ich sie in den letzten Artikeln beschrieben hatte. Ich habe ein paar Refactorings vorgenommen, insbesondere in dem Bereich, wo es um den Zugriff auf die Mastodon API und OpenSearch geht. Die Konfiguration der Instanzen und Nodes, Client-IDs, Secrets und Login-Daten werden jetzt natürlich nicht mehr in den Scripten sein. Gerade Mastodon.py unterstützt sehr gut dabei, dass man von Anfang an die Konfiguration von dem Script-Code trennt. Ich hatte das nur bei den Beispielen erstmal gelassen, weil sie so schneller auszuprobieren waren.

Da jetzt die Snippets auch aus dem git zu laden sind (und damit auch mal komplexer sein können), ist es klar, dass solche “Komfortfunktionen” integriert werden können, ohne auf den einfachen Charakter des Blogs verzichten zu müssen. D.h. hier bleiben die Beispiele einfach und skizzieren, wie man Lösungen anstrebt und im Repository finden sich dann besser ausformulierte Lösungen.

Modul MastodonHelper

Damit man komplett unabhängig von den Scripten aus dem git-Repository eine eigene Konfiguration speichern kann, zudem weder im Mastodon-Web UI die App registrieren muss, noch User/Password lokal speichern muss, um in Zukunft die Scripte automatisiert ausführen zu können, kommt hier ein kleines Helper Modul, dass mit einem Methoden-Aufruf alles erledigt.

Die wichtigste Funktion in dem Helper ist open_or_create_app(...). Das ist ein Multitalent und ist in der Lage, die Scripte als App zu registrieren, sich entweder nur als Client-App oder User-Account anzumelden und dann die Registrierungs-Daten und den Zugriffstoken des Accounts lokal zu speichern, damit beim weiteren Aufruf weder die App erneut registriert wird noch man die Login-Daten wieder eingeben muss.

Da das kaum in Worte zu fassen ist, ein Aktivitätsdiagramm (erstellt mit <plantuml.org>):

Activity

Man kann die Funktion in drei große Abschnitte aufteilen:

Prepare Configuration

Der Teil der Methode übernimmt entweder die notwendigen Parameter von dem Funktions-Aufruf oder liest diese aus einer Config-Datei. Die Config-Datei wird erst im Home-Ordner gesucht, dann im Script-Ordner. Man kann auch einen absoluten Pfad angeben. Legt man aber in dem eigenen Home-Ordner die Datei `mastobot-config.yaml’ an, kann man die Beispielscripte ohne Modifikation sofort ausführen (gesetzt den Fall, man hat die Konfiguration angepasst).

Alle Konfigurationsparameter werden auch grob geprüft und man bekommt ggf. Fehler um die Ohren gehauen.

Register Application

Der Abschnitt sucht erstmal, ob wir unter dem konfigurierten Application-Name schon Client-App-Daten in eine .secret Datei gespeichert haben. Wenn nicht, wird eine App unter dem Namen und der gewünschten Default-Instanz registriert (siehe `mastobot-config.yaml’).

Mit der erfolgreichen Registrierung, werden die Client-ID und das Secret in eine Datei gespeichert und, wie oben beschrieben, in Zukunft immer wieder verwendet. Das verhindert, dass eine App immer neu registriert wird (was Podmins der Mastodon-Instanzen zu schätzen wissen).

Connect to Mastodon

Der dritte Abschnitt in der Methode ist das Kernstück.

Erst wird geschaut, ob ein Account-Login gewünscht wird und der Access-Token des Users schon mal gespeichert wurde (das ist der linke Pfad im Aktivitätsdiagramm). Wenn ja, werden die Daten aus dem HOME-Ordner geladen und Mastodon.py meldet sich mit den Daten an.

Der längere Weg ist im rechten Pfad beschrieben. Zunächst sagen wir Mastodon.py welche Client-ID und Secret genommen wird (das haben wir früher mal, oben bei Register Application, gespeichert). Danach prüfen wir, ob wir einen User-Account-Login wollten (über den Parameter login = True). Wenn ja, dann fragen wir den Benutzernamen und Password im Terminal ab (Yeah, ein UI!), loggen uns damit bei unserer Mastodon-Instanz ein, bekommen dann einen Access-Token und speichern diesen auch im Home-Ordner ab. Puh. Warum? Damit wir bei allen zukünftigen Aufrufen nicht mehr ein interaktives Login haben!

Anders gesagt: Wir müssen uns nur ein einziges Mal anmelden und danach laufen alle Scripte automatisiert, ohne Interaktion, durch.

Schaut euch auf Codeberg das Modul mal an: MastodonHelper.py.

Da sind noch ein paar weitere Hilfsmethoden drin. Die sollen aber das alles nur etwas strukturieren.

me.py

Wie wird das nun verwendet? Dazu habe ich ein winziges Script geschrieben: me.py:

import json
import mastobot.MastodonHelper


mastodon = mastobot.MastodonHelper.open_or_create_app(
    config_yaml='mastobot-config.yaml',
    login=True
)

# Request my account data:
me = mastodon.me()

# Print out basic stuff:
print("\n\n")
print(f"Me: {me['id']} = {me['username']}")

# Print out everything:
print(json.dumps(me, indent=4, default=str))

Der obige Aufruf von open_or_create_app wird, wenn ihr nichts an der mastobot-config.yaml geändert habt, nur Fehler werfen.

Also kopiert die mastobot-config.yam Datei in euren Home-Ordner.

Tragt bei name: ~ statt der ~ einen Namen ein, der eure App eindeutig identifiziert, zum Beispiel:

application:
  name: HorstsMastodonApp
  debug: false  # debug output

Im Abschnitt der instances tragt ihr eure Mastodon-Instanz ein, wo ihr einen Account habt:

instances:
  default:
    url: https://social.example.com # your instance URL

Das muss eine vollständige URL sein (und natürlich nicht https://social.example.com).

Jetzt ruft das me.py Script auf.

Ihr werdet einen Login bekommen, wo ihr eure E-Mail-Adresse und das Password eingeben müsst. Keine Angst, die Daten werden lokal nicht gespeichert. Klappt das Login damit, wird im Home-Ordner eine .usertoken Datei angelegt, wo nur eine ID drinsteht. Diese ID sollte niemals in andere Hände gelangen. Das ist ein Zusatzschlüssel, mit dem ihr euch einloggen könnt, ohne Benutzername und Kennwort angeben zu müssen. Das ist sozusagen eine “Hotel-RFID”-Karte zu eurem Zimmer im Mastodon-Instanz-Hotel.

Wenn das alles geklappt hat, bekommt ihr ein großes JSON mit euren Account-Informationen.

Ruft ihr das Script me.py nochmal auf, läuft es einfach durch und das JSON wird wieder angezeigt. Keine Registrierung, kein Login.

Das funktioniert jetzt mit jedem Script auf eurem Rechner, dass den MastodonHelper mit der open_or_create_app Funktion und den gespeicherten Konfigurationsdaten nutzt.

Also jedes Script mit dem Aufruf:

import mastobot.MastodonHelper


mastodon = mastobot.MastodonHelper.open_or_create_app(
    config_yaml='mastobot-config.yaml',
    login=True
)

Loggt sich völlig automatisiert ein.

Mit dieser Vorbereitung, werden alle weiteren Scripte, die ins git-Repository hochgeladen werden, sehr simpel im Prolog sein.

Viel Spaß damit!

Wie immer: Wenn ihr in eurer Bubble Menschen vermutet, die sich für solche Artikel interessieren, dann boosted! Danke :-)