Golb Slexa ::

Um ein Web oder ein Verzeichnis mit Username und Passwort zu schützen, kann man mit Basic Authentication arbeiten. Man kann Benutzer oder Gruppen berechtigen, eine Seite zu öffnen.
Dazu hatte ich kürzlich 2 PHP Klassen zum Verwalten von htpasswd- und htgroup-Dateien veröffentlicht. Diese kann man in Programmierprojekten einsetzen.

Nun habe ich mit jenen Klassen ein Konsolen-Werkzeug in PHP geschrieben, um Benutzer und Gruppen auf etwas bequemere Art und interaktiv im Terminal zu verwalten. Das Tool benötigt keinerlei fremde Werkzeuge, wie openssl oder htpasswd, um die Benutzerpasswörter zu erstellen.

Und so sieht das Ganze aus:

Mit -h oder –help sieht man die unterstützten Parameter. Man wählt mit –folder ein Verzeichnis (Default ist das das aktuelle Verzeichnis) und darin wird eine Datei mit Benutzern und eine für Gruppen verwaltet.

Es gibt ein wenig Comfort.

• Beim Löschen von Benutzern wird gewarnt, wenn dieser in Gruppen ist.
• Bei der Eingabe von Benutzernamen oder Gruppen gibt es eine Vervollständigung: mit der Tab-Taste kommt man schneller ans Ziel.
• Das Auflisten von Benutzern zeigt deren Gruppenzugehörigkit an - das Listing der Gruppen die Mitglieder.
• Eine Check-Funktion zeigt nicht existierende Gruppenmitglieder, User ohne Gruppen.

Dieses lässt sich mit SPC zu einem Binary compilieren. Für Linux werden vorcompilierte 64-Bit Binaries bereitgestellt. Im Projekt-Quellcode ist ein ./compiler/ Verzeichnis in dem der Download und Installation von SPC und das Compilieren zur ausfühtbaren Datei mitgeliefert wird.

Euer Hosting oder lokaler Rechner läuft mit Linux? Dann könnt ihr das Binary dorthin kopieren - nach Möglichkeit in ein Verzeichnis von $PATH. Und (nach SSH-Login) in der Konsole htpasswd- und htgroup-Dateien bearbeiten.

Euer Rechner/ Hosting hat PHP bereits an Bord? Dann kann man auch die gemergte PHP-Datei auf das Zielsystem kopieren und jenes auf der Konsole starten (per oder aber php )

Das Tool ist Freie Software unter GNU GPL 3 und kann kostenlos eingesetzt werden.

Weiterführende Links:

• Github: Sourcecode von htman
• Releases - vorcompiliertes Linux-Binary und gemergte PHP-Datei für Endanwender
• static-php.dev - SPC compiler - macht aus einem PHP-Skript eine ausführbare Datei
• Github: Sourcecode der htpasswd-Klassen

Ich habe so diverse Applikationen, die einen Passwortzugang für ein Backend benötigen.

Für so kleinere Sachen reicht eine .htpasswd-Datei und Basic Authentication. Um diese per PHP zu erzeugen und zu bearbeiten, habe ich keine geeignete Klassen gefunden … ergo schrieb ich sie mal selbst :-)

Das Projekt besteht aus je einer Klasse für die Verwaltung einer .htpasswd Datei und einer für die .htgroups. Sie können diese Dateien auslesen, Gruppen oder User hinzufügen oder aber löschen. Mit diesen PHP-Klassen kann man eine Benutzerverwaltung mit reinen PHP-Mitteln und ohne ein exec() der htpasswd Datei umsetzen.

Die Dokumentation enhält zudem Konfigurationsbeispiele verschiedener Szenarien für .htaccess Dateien.

Ich hoffe, der ein oder andere findet diese Klassen nützlich.

Weiterführende Links:

• Sourcecode: Github
• Dokumentation (en)

Es hat 1.5 Jahre gebraucht vom ersten Entwurf bis zur Veröffentlichung. Scheinbar ist es komplizierter, als gedacht. Aber nun ist es vollbracht: der Artikel ist online.

Ich bin seit 12 Jahren am IML angestellt und erstmals sind Worte wie “Open source” oder “Freie Software” in einem Artikel unserer Instituts-Webseite aufgetaucht. Und das, obwohl seit über 10 Jahren in der Server-IT ausschliesslich Linux und Freie Software zum Einsatz kommt.

Was braucht es, um im Blick zu halten, ob die Infrastruktur rund läuft? Wir verwenden mehrere Monitoring-Werkzeuge für

• Logging
• Cronjobs
• System-Monitoring und
• Applikations-Monitoring

Das System-Monitoring Icinga2 ist unser zentraler Sammelpunkt, bei der Störungsinformationen zusammenfliessen - so hat man alles im Blick, ohne zwischen verschiedenen Fenstern (Tabs) hin- und herspringen zu müssen.

Wir setzen auf Freie Software und stellen im Umkehrzug Eigenentwicklungen als Freie Software zur Verfügung.

Am konkreten Beispiel unseres IT Monitorings wird das gelebte Prinzip von Nehmen und Geben beleuchtet.

Link: IML Webseite: IT-Monitoring mit “Freier Software”

Hier ein weiterer Javascript-Schnipsel…

Manchmal möchte ich in einer webbasierten Admin eine Schaltfläche haben, die etwas löscht oder eine Aktion auslöst, die aber nicht mit einem GET Request ausgelöst werden können soll. Also mein A-Tag oder Button-Tag soll beispielsweise einen POST request auslösen und Parameter mitgeben können. Aber auch PUT oder DELETE Requests sind möglich.

Die nachfolgende Funktion führt einen Http-Request aus und zeigt den Output in einer DOM-ID oder aber bei Fehlen der ID im gesamten Browser-Fenster. Wobei Letzteres noch den schönen Effekt hat, dass ein F5 im Browser-Fenster den POST request nicht wiederholt.

/**
 * Make an http request with given method, url, form data.
 * The response can be shown in a given dom id or in the full browser window.
 * 
 * @param {string}  method  http method; eg. GET, POST, PUT, ...
 * @param {string}  url     url to request
 * @param {json}    data    request body as key -> value in a JSON
 * @param {string}  idOut   optional: id of output element in DOM; default: write response in browser
 * @return void
 */
async function httprequest(method="GET", url = "", data = {}, idOut = null) {

    // console.log("httprequest("+method+", "+url+", "+data+", "+idOut+")");

    if (method == "POST" || method == "PUT") {
        var fd = new FormData();
        for (var key in data) {
            fd.append(key, data[key]);
        }
    } else {
        var fd = null;
    }

    // Default options are marked with *
    const response = await fetch(url, {
        method: method, // *GET, POST, PUT, DELETE, etc.
        mode: "cors", // no-cors, *cors, same-origin
        cache: "no-cache", // *default, no-cache, reload, force-cache, only-if-cached
        credentials: "same-origin", // include, *same-origin, omit
        headers: {
            // "Content-Type": "application/json",
            // 'Content-Type': 'application/x-www-form-urlencoded',
            // 'Content-Type': 'multipart/form-data',
        },
        redirect: "follow", // manual, *follow, error
        referrerPolicy: "no-referrer", // no-referrer, *no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url
        body: fd, // body data type must match "Content-Type" header
    });
    // return response.json(); // parses JSON response into native JavaScript objects

    var responsebody = await response.text();
    if (idOut) {
        document.getElementById(idOut).innerHTML = responsebody;
    } else {
        document.open();
        document.write(responsebody);
        document.close();
    }

}

Und so wird sie verwendet:

Nachfolgendes HTML-Snippet zeigt einen Button. Beim onclick-Event sehen wir die obige Funktion einmal eingebunden.
Man sieht

• die Http-Methode: POST
• die aufzurufende URL: die aktuelle - mittels location.href
• POST-Parameter: als JSON wird die Variable “action” mit dem Wert “backup” übergeben. Mit PHP liesse sich dies mit $_POST['’action’] lesen.

<button 
  class="btn"
  onclick="httprequest('POST', location.href , {'action': 'backup'})" 
>Create new backup</button>

Die Funktion ist noch nicht featurecomplete. Sie kann noch erweitert werden, um Http-Request-Header mit zu übergeben. Aber ich hoffe, für den ein oder anderen ist sie bereits in dieser Form nützlich.

Weiterführende Links:

• developer.mozilla.org: Fetch API (en)

PHP 8.4 ist seit Ende November live.

Meine PHP-Klasse ahCache, die beliebige Daten (Strings, Hashes, Objekte) im lokalen Dateisystem cachen kann, ist hiermit offiziell PHP 8.4 kompatibel. Es musste lediglich eine Methode angepasst werden. Das war um Glück überschaubar.

Die Dokumentation wurde gleichsam umgestellt. Sie ist nun im Repository direkt enthalten und wird - wie schon eineige meiner anderen Projekte - mit Daux.io gerendert.

Weiterführende Linke

• Github: Sourcecode von ahCache
• Docs: ahCache

Mit Bash code ich diverse Sachen, um mir das Admin Leben zu vereinfachen.

Sobald man JSON Dateien oder JSON als API-Response vor sich hat, ist plattformübergreifend jq das Tool der Wahl für ein schnelles Pretty Print oder seinen starken Filter-Funktionen.

Wenn ich in einer Variable die komplette Liste hineinhole …

# Holen einer JSON-Liste
$OUT_TOKENS= $( curl $URL )

Für jeden Eintrag wünsche ich eine Verarbeitung. Mit seq kann ich von 1 .. N loopen. Die Anzahl der Elemente müssen wir uns daher zunächst einmal holen. Am enfachsten, wenn ich eine “id” oder einen anderen Key drin habe.

# IDs / Einträge zählen:
iTokenCount=$( jq ".[].id " < "$OUT_TOKENS" | wc -l )

Mit einem jq Filter kann ich mir innerhalb der Schleife das N-te Element aus der Variable $OUT_TOKENS herausziehen, in eine eigene Variable legen und dann anschliessend jene zerlegen.

Snippet:

# einmal drüber loopen
for i in $( seq 1 $iTokenCount )
do

   # get N-th token
   entry="$( jq ".[$i]" < "$OUT_TOKENS")"

   # ...

done

Nehmen wir mal an, ich möchte aus jedem Listen-Eintrag den Key “name” auslesen. Und vielleicht noch einen 2. oder 3…
Dann schreibt man zunächst eine kleine Funktion

# Get a single value from json
# param  string  json data
# param  string  key
# return string
function getKey(){
    jq -r ".$2" <<< "$1" | grep -v "null"
}

… welche man dann innerhalb des Loops verwendet:

for i in $( seq 1 $iTokenCount )
do

   # get N-th token
    entry="$( jq ".[$i]" < "$OUT_TOKENS")"

    sName=$( getKey "$entry" "name" )
    if [ -z "$sName" ]; then
        continue
    fi

    sExpire=$( getKey "$entry" "expires_at" )

    # ...
done

Weiterführende Links

• jq webseite (en)

Ich habe für diverse Projekte eine PHP-Entwicklungsumgebung. Mittlerweile als Docker Container.

Wenn meine Applikation in der Live Umgebung Emails versendet - wie gehe ich damit in der Dev-Umgebung um?

Ich wollte einen Email-Catcher haben, der statt Sendmail oder Postfix die Emails zu versenden, für mich abfängt.
Zum Glück ist das nicht soo schwer, dies ohne weitere Abhängigkeiten zu coden. So entstanden eine PHP-Klasse und 2 Skripte: eines, um die Emails vom STDIN einzufangen - und ein Viewer.

Ganz wichtig: es musste einfach zu verwenden sein! Voila: die Konfiguration besteht aus einer Zeile in der php.ini.

Wenn du in einer PHP Enwicklungsumgebung die versendeten Email abfangen und lesen willst: hier ist ein quick winner!

📜 License: GNU GPL 3.0
📄 Source: https://git-repo.iml … rce/php-emailcatcher
📗 Docs: https://os-docs.iml. … ch/php-emailcatcher/ (en)

Screenshots - so sieht es aus:

Und so geht es:

Installation mit Git:

Unterhalb des Webroot lege ich im Unterverzeichnis “vendor” die Software ab.

cd [WEBROOT]
cd vendor
git clone https://git-repo.iml.unibe.ch/iml-open-source/php-emailcatcher.git emailcatcher

Einfangen der Email aktivieren:

In der php.ini ist mit sendmail_path auf das Skript php-sendmail.php zu verweisen.

[PHP]
...
sendmail_path = "php [WEBROOT]/vendor/emailcatcher/php-sendmail.php"

Anm: Sofern php nicht im Pfad ist, muss man statt “php ” den kompletten Pfad angeben z.B. “/usr/bin/php “.

Test-Email versenden.

Viewer starten.

Unterhalb “vendor” ist im emailcatcher Verzeichnis eine viewer.php - die öffnet man im Webbrowser.

Z.B.: http://localhost/vendor/emailcatcher/viewer.php

Tja, und das war es bereits. Viel Spass damit!

Update:

Wenn man HTML Emails versendet und das Layout ansehen möchte, dann brauchte es in der präsentierten Version einige Klicks. Unnötige Klicks. Und immer wieder. HTML Emails wollte ich dann doch direkt sehen können. Im Localstorage des Webbrowsers wird sich der letzte Zustand der Anzeige gemerkt: Header anzeigen ja oder nein - und Ansicht als HTML oder Source.
Sieht wer weiteres Verbesserungspotetial zur Effiziensteigerung? Lasst es mich wissen oder macht einen Pull-Request.

An meinem Institut habe ich ein Projekt für eine Logon-Seite mit AAI / EduGain in einer funktionsfähigen Version released.

AAI ist eine Anmeldeform im universitären Bereich. Studierende und Dozenen anderer Universitäten melden sich mit dem Account ihrer eigenen Universität bei ihrem gewohnten Anmeldeprovider (IDP) an. Wenn die Authentifizierung erfolgreich war, dann kann der fremde IDP unserer Applikation den Erfolg des Logons in Form einer ID sowie einige minimale Metadaten senden. Mit jener ID lässt sich in der eigenen Anwendung ein User anlegen oder wiedererkennen. Regelbasiert oder manuell administrativ kann man einem Account Gruppen und Rollen zuweisen.

Das gibt es alles schon und ist spezifiziert, dokumentiert und schon lange produktiv im Einsatz. Sowas erfindet man nicht neu.

Mein Pro AAI Login ist in PHP programmiert - und folglich hilfreich für eine PHP-Anwendung mit Shibboleth. Der Ursprung der Entstehung war eine Ilias9 Installation.In früheren Ilias Versionen konnte man für die Start-/ Anmelde-Seite HTML-Code und Javascript einbinden. Auf diese Weise wurde ein externes Javascript WAYF (=Where are you from) von Switch eingebunden. Das funktionierte super.
In Ilias 9 kann man seine Startseite umfangreich zusammenklicken, aber Javascript konnte ich nicht einbetten. In Feldern für HTML-Code wurde es nach dem Speichern ausgefiltert. Nachdem ich mit dem Anmelde-Konfigurator aufgegeben hatte, sollte eine Seite her, die die Aufgabe der Anmeldeseite übernimmt. Zwar ist initial Ilias das erste Ziel-Projekt, aber es ist bewusst flexibel konfigurierbar ausgelegt, so dass es sich für andere Shibboleth geschützte Anwendung einsetzen liesse.

Die Logon-Seite bietet eine Liste der zugelassenen IDPs an. Mit enem Filterfeld lassen sich auf Tastendruck die angezeigten IDP reduzieren, damit ein Benutzer schnell das eigene Login finden kann.

Der Filter nach TLD (Länder-Domains) wird automatisch bereitgestellt.

Die Anmelde-(Auswahl-)Seite unterstützt Mehrsprachigkeit, mehrere Layouts (als Boxen, Liste, WAYF Auswahlseite). Hier die mitgelieferte Darstellungsform als Liste:

Weiterhin ist es flexibel bezüglich

• Sprachen. Ein deutsches und englisches Spachfile sind mitgeliefert. Der Aufwand für ein neues Sprachfile ist sehr überschaubar
• Ausgabetexte: Es gibt 3..4 Textelemente, die man frei konfigurieren kann. So kann man den HTML-Code vor und nach der Provider-Auswahl anpassen.
• Layout der Provider-Ausflistung: es werden 3 Layouts mitgliefert. 2 davon sieht man in obigen Screenshots. Ein neues Layout lässt sich schnell erstellen. Eine Klasse liefert bereits alle nötigen Daten, die man nur noch im gewünschten HTML-Code ausgeben lassen muss. Jedes Layout wird seine eigene CSS Datei einbinden - damit ist man völlig frei in der Gestaltung
• Farben: das Basislayout kommt von einer vorgegebenen CSS Datei. Mit Hilfe einer eigenen CSS Datei kann man alle CSS Rules üübersteuern und das Gesamtlayout verändern.

Die Lizenz erlaubt kostenfreie Verwendung, Einsicht in den Quellcode und Anpassung jedweder Art.
Feedbacks und Verbesserungsvorschläge sind willkommen.

📜 License: GNU GPL 3.0
📄 Source: https://git-repo.iml … pen-source/login-aai
📗 Docs: https://os-docs.iml.unibe.ch/login-aai/

Ich habe eine Sprachdatei für ein PHP-Skript in einer JSON Datei abgelegt.
Meine HTML Seite sollte in der eingebundenen Javascript-Datei die Datei ebenfalls laden und deren Inhalt einer Variable “aLang” zuweisen.

Sicher geht es noch eleganter, aber ich bin bei diesem Snippet hängengeblieben:

var sLang='de-de';
var aLang={};

(...)

/**
 * Init step 1: load language file and make it available in aLang
 */
async function init(){
    fetch('lang/' + sLang + '.json')
    .then(response => response.json())
    .then(aLang => {
        initStep2(aLang)
    })
    .catch(error => console.log(error))
    ;

}

/**
 * Init step 2
 */
async function initStep2(langArray) {
    aLang = langArray;

    // just to check it in the console:
    console.log(aLang);

    // optional: next js function to call or more js code
}

// MAIN
init();

Der IML Appmonitor dient der Ergänzung unseres Systemmonitorings. Aus Sicht einer Applikation werden Prüfungen vorgenommen, die in ihrer Summe eine Aussage treffen, ob eine Applikation gerade lauffähig ist. Sei es die Verfügbarkeit von Ressourcen, APIs oder Datenbanken, Schreibzugriffe auf Upload Folder. Auch sollte man umgekehrt schützenswerte Informationen prüfen, ob diese bei gewöhnlichen Http-Anfragen eben nicht ausgeliefert werden und ein 40x Fehlercode melden.

Man kann Prüfungen miteinander verknüpfen, z.B. muss eine Konfigurationsdatei lesbar sein - die z.B. Credentials für eine Datenbank besitzt - dann ist die Prüfung der Datenbankverbindung von der Lesbarkeit der Konfigurationsdatei abhängig. So kann man einen Abhängigkeitsbaum zu visualisieren, der einem Projektmanager ein klareres Bild zu einer Störung vermitteln kann.

Im Zuge des Updates unserer PHP-Applikationen habe ich den PHP-Code unter PHP 8.3 aktualisiert:

• Bisher ist alles untypisiert gewesen. In Klassen wurden Variablen, Parameter von Methoden und deren Returncode typisiert (also eine Angabe, ob eine Variable ein String, Integer, Array, Objekt, … ist). Das hilft dem Compiler bei Optimierungen und sichert den Code ab. Ist aber auch - bei mechanischem, visuellen Ersetzen auch etwas fehleranfällig.
• PHPDoc wurde in allen Methoden geprüft - da gab es doch viele Kommentar-Sektionen, die nicht mit dem Code übereinstimmten
• Alle Arrays und Hashes wurden auf die verkürzte Array-Schreibweise umformatiert.
• Die Markdown-Hilfedateien wurden überarbeitet

Kurz: ohne Funktionalitätsgewinn wurden ein paar tausend Zeilen in 70+ Dateien geändert und heute gemergt: https://github.com/i … onitor/pull/88/files

Aber dem Programmcode tut es sicher gut, gelegentlich auf einen aktuelleren Stand gehoben zu werden.

Gleichartiges widerfuhr letzte Woche dem Code unseres Intranets.

Weiterführende Informationen:

• 🧾 Sourcecode: https://github.com/iml-it/appmonitor
• 📜 License: GNU GPL 3.0
• 📗 Docs: https://os-docs.iml.unibe.ch/appmonitor/