Webinterface für command line utilities

[sanbiber]

Hi,

da immer weniger Leute eine (Unix-)Shell benutzen (können) und das für einige Projekte ein show-stopper zu sein scheint (bis eine richtige/einfache/"intuitive" GUI entwickelt wurde), ist mir der Gedanke gekommen, das vielleicht ein einfaches Webinterface (für das der User dann auch kein runtime-environment für die Skripte / Programme und keine Anleitung über "Kommandozeilenparameter" zu lesen braucht) anzubieten, das Eingaben annimmt (auch Eingabedatei), es an die eigentliche Anwendung weiterreicht und die Ausgaben (auch Ausgbabedatei) und ausgibt. Es muss nicht soviel können wie das eigentliche Programm, aber es soll Kernfunktionalitäten bieten, um die Hürde für neue User möglichst niedrig zu legen.

Die Frage ist, ob hier jemand ein einfaches und gebräuchliches Tool/Framework kennt, was sowas tut. Wichtig wär mir, dass keine gefährlichen Eingaben gemacht werden können, dass das Tool also irgendwie sowas abfängt. Verschlüsselung und so könnte gut von nem vorgelagerten reverse proxy erledigt werden - das muss es nicht können. Datenbank ist auch nicht nötig.

Vielen Dank,
sanbiber

PS: Der wirkliche Grund ist natürlich, dass ich am Liebsten unter FreeBSD kleine Skripte oder Kommandozeilen-Programme schreibe ... die dann aber kaum genutzt werden können von Leuten, die immer mehr nur "Apps" gewohnt sind ...

 

[CommanderZed]

Hmm ich hab das jetzt 3, 4 mal durchgelesen und bin mir nicht ganz sicher was du genau machen möchtest.

 

[Andy_m4]

Also grundsätzlich ist es nicht verkehrt bei Programmen die eigentliche Funktionalität und sozusagen das Benutzer-Interface zu trennen. Das macht es dann einfacher möglich ein beliebiges Interface einzusetzen. Ob das nun ein Kommandozeilen-Interface ist oder eine klassische GUI oder ein Webinterface oder das man gar alles anbietet, wird dann natürlich einfacher.

De-facto wird das auch ganz oft gemacht. Viele Kommandozeilentools sind jetzt schon lediglich Frontends für entsprechende Bibliotheken.

da immer weniger Leute eine (Unix-)Shell benutzen (können) und das für einige Projekte ein show-stopper zu sein scheint

Wobei man ganz klar sagen muss, die Stärke der Shell liegt ja darin, das man quasi ein Werkzeug-Set hat und diese Werkzeuge z.B. mit Hilfe von Pipes usw. kombinieren kann um das eigentliche Problem zu lösen, was man hat.
Das 1:1 in eine GUI zu gießen ist zumindest ähm ... schwierig und oftmals auch gar nicht zielführend. Nicht zuletzt deshalb, weil es zu komplizierten GUIs führen würde die für den "normalen Anwender" ebenso verwirrend sind wie die Kommandozeile.

Meist geht es daher bei GUIs auch darum nicht zu bestimmte Dinge zugänglicher zu machen und einfacher zu strukturieren, sondern auch zu reduzieren. Einfache Bedienung hat vor allem mit der Reduktion der Möglichkeiten zu tun.

Die Frage ist, ob hier jemand ein einfaches und gebräuchliches Tool/Framework kennt, was sowas tut. Wichtig wär mir, dass keine gefährlichen Eingaben gemacht werden können, dass das Tool also irgendwie sowas abfängt.

Wie gesagt: Wenn man Frontend und Backend (zumindest von der Programmlogik her) trennt, ist das schon die halbe Miete.

Es gibt jetzt kein fertiges Tool mit dem man sagen kann: Bastel mir aus einem beliebigen Kommandozeilenprogramm eine GUI. Denkbar wäre das. Nämlich indem man eine programmatisch auswertbare Beschreibung hinterlegt, welche Optionen es gibt, welche Werte dort möglich sind. Welche Option sich mit welcher kombinieren lässt. Hat man sowas, dann kann man sogar (teil-)automatisiert sich sein Frontend erzeugen lassen.
Ob es sowas fertig gibt, kann ich Dir gar nicht beantworten. Wenn, dann ist das tatsächlich eher die Kategorie Framework und Du müsstest Deine eigenen Programme dann sozusagen gegen dieses Framework schreiben.

Nichtdestotrotz müsstest Du aber erst mal in Vorleistung gehen und halt mehr implementieren als Du das im Augenblick tust um dann davon profitieren zu können.

Der wirkliche Grund ist natürlich, dass ich am Liebsten unter FreeBSD kleine Skripte oder Kommandozeilen-Programme schreibe ... die dann aber kaum genutzt werden können von Leuten, die immer mehr nur "Apps" gewohnt sind ...

Wie Lösungen oder besser gesagt: eine Vorgehensweise dazu konkret aussehen können hängt davon ab, in welcher Sprache Du programmierst und wie Deine Skripte denn ungefähr aussehen. Du wirst auch etwas Erfahrung mitbringen (oder erarbeiten) müssen, wie man Web-Interfacesdenn umsetzt usw.

Ich sag mal jetzt so salopp: Wenn Du eher nur Skripte mit externen Kommandos und bash-builtins baust sind die Möglichkeiten etwas begrenzter da ein Web-Interface dranzubasteln als wenn Du z.B. Deine Skripte in Python schreibst.

Vielleicht kannst du ja auch mal die Funktion eines konkreten Skripts erläutern damit wir hier mal was "in der Hand" haben und dann nicht immer abstrakt über irgendwas reden, wovon letztlich jeder ein anderes Bild im Kopf hat.

 

[sanbiber]

Ein Beispiel wäre, dass aus einer PDF-Datei eine Broschüre erstellt werden soll. Eingabe wäre z.B. eine PDF-Datei mit einzelnen A4-Seiten im Hochformat und eine (Inhalts-)Seite pro A4-Seite, Ausgabe wäre eine PDF-Datei mit A4-Seiten im Querformat und jede neue A4-Seite enthält zwei Ursprungs-A4-Seiten (auf A5 geschrumpft) in so einer Anordnung, dass, wenn die Seiten der Ausgangsdatei der Reihe nach gedruckt werden durch Faltung und Inneinanderlegen eine Broschüre entsteht.

Diese Logik/dieses Backend existiert bereits (über CLI steuerbar).

Ich würde nun gern ein Webinterface haben, was das Skript (oder ein Wrapper-Skript, wenn mehrere Aufrufe nötig sind) mit den passenden Parametern füttert und die Ausgabe des Skripts zurück gibt. Das soll bei allen möglichen Anwendungen gehen, die eine CLI haben und über CLI gesteuert werden (von bourne shell bis bash, von perl bis python ...). Das Webinterface soll also immer nur über das CLI auf die Anwendung(en) zugreifen. Also sozusagen das CLI als API nutzen.

(Ich suche kein Webinterface für eine Shell, keine Shell/kein xterm im Browser!)

 

[Andy_m4]

Das Webinterface soll also immer nur über das CLI auf die Anwendung(en) zugreifen. Also sozusagen das CLI als API nutzen.

Und woran hakt es jetzt konkret? :-)

Also man könnte sich ja (ich greif das mal auf, weils genannt wurde) ein Python-Skript basteln was ein Webserver startet und z.B. gleich noch im Browser die entsprechende Adresse ( http://127.0.0.1:36000 oder wie auch immer) aufruft. Der Webserver liefert die GUI aus und über HTML-Formular-Elemente könntest Du dann die ganzen notwendigen Sachen vom Nutzer einsammeln und das Request an den Webserver schicken, der reicht das aufbereitet wiederum an dein CLI-Skript weiter und fertig ist die Laube.

An welcher dieser Punkte hakt es denn konkret?

 

[sanbiber]

Es gibt im Moment noch kein Interface außer dem CLI.

Genau, @Andy_m4, so hab ich mir das auch gedacht, wenn ich das selbst/neu machen würde.

Aber vielleicht gibt es ja schon Frameworks, die genau für so ein Use-Case gebaut wurden oder das einfach unterstützen, im Einsatz sind und eine gewisse Robustheit aufweisen. Insbesondere will ich mich eigentlich nicht groß mit HTML, CSS, Javascript? und Eingabevalidierung herumschlagen. Auch der Dateiup- und -download wird von so einem Framework idealer Weise schon erledigt ...

 

[Andy_m4]

Insbesondere will ich mich eigentlich nicht groß mit HTML, CSS, Javascript

Ganz ohne wird es nicht gehen. Insbesondere mit HTML und CSS baut man ja die GUI.

Ansonsten werde ja sicher die Python-Profis hier mal was konkretes dazu nennen.
Meine Python-Kenntnisse sind eher bescheiden. :-)

 

[serie300]

Ist jetzt nicht html, aber hast du dir den dialog Befehl mal angeschaut? So wie ich es verstehe willst du vermeide, daß der Benutzer irgendwelche kryptische Parramezerangaben macht.

 

[sanbiber]

Ja, das kenn ich. Direkt das zu nutzen ist aber für mich keine Lösung (da Entkoppelung von OS und Anwendung und niedrige Hürde erreicht werden soll).

 

[foxit]

Ich bin nicht der Programmierer aber ich habe mit Flask[1] und Bootstrap[2] ein kleine Wake-On-Lan Seite erstellt, wo die Mitarbeiter nach der VPN Verbindung ihren PC in der Firma aufwecken können. Das ganze sind vielleicht 30-40 Zeilen Code.

Ansonsten finde ich auch, wie @serie300 sagt: Dialog für solche Sachen ganz gut. Ich habe auch so eine Lösung laufen, wo die Lehrlinge auf einem Server verschiedene Dienste neu starten können. Wenn der Prozess von Dialog stirbt oder beendet wird, loggt sicher User sofort wieder aus...

[1] https://flask.palletsprojects.com/en/1.1.x/quickstart/
[2] https://getbootstrap.com/docs/4.5/components/forms/

 

[Athaba]

Ganz wichtig dabei:


Parameter parsen und wenn's geht generell nur fixe Were nutzen (also Dateien mit fixem oder vollständig vom Server generierte Namen). Schauen, dass alle Zahlen Zahlen sind und ganz generell nichts was vom Client kommt ausführen. Im Besten Fall macht man wohl ein Form, überlegt sich eigene Namen für die Optionen und macht dann selbst einen Befehl draud. Bei einem File-Upload speichert man die Datei unabhängig vom Namen im File-Upload selbst. Sollte man Zahlen-Eingabe haben auch entsprechend parsen, und dann auf Größen-Limit aufpassen. Und ganz generell eine gute Idee zu verhindern, dass man jegliche Parameter aufblasen kann. Eventuell noch ein Request-Limit und/oder eine Queue dazwischen.

Wenn's geht Jail, eigener User, Pledge/Unveil (damit kann man recht einfach verhindern das geforkte Software was anstellen kann), etc. verwenden.

Je nachdem was es können soll: Ohne JS kommst du aus, wenn es ein normales Form ist und es okay ist, dass während dem Befehl-Ausführen die Site einfach lädt. Ausgehend von dem kann man ja, wenn man doch mehr machen will optionales JS dranbauen.

Ansonsten, manchmal gibt's CLI-Tools auch in Libraries gewrapped. Nur da auch aufpassen, auch wenn das Library von vielen Leuten, Produktiv genutzt wrid. Wäre nicht das erste Mal, dass so etwas trotz vielen Usern gravierende Mängel hätte.

 

[bsd4me]

Um Bezug auf die Eingangsmail zu nehmen: das kenne ich auch, auch bei Leuten die bei mir am Lehrstuhl programmieren. Ich versuche den Leute immer wieder beizubringen, dass die Kommandozeile eine super Möglichkeit ist was zu machen, in sehr vielen Fällen viel effizienter als der GUI Kram. Es ist schade, dass das so wenig genutzt wird. Also: Aussen GUI - innen PFUI Aber so ist es oftmals ;-) Naja, GUIs haben auch ihre Berechtigung, aber ein wenig Kenntnisse im Terminal / Shell ist doch sinnvoll - Norbert

 

[juedan]

Moin sansiber,
grundsätzlich ist es kein Problem, in PHP, Perl oder sonstwas eine Web-GUI zu basteln. Der Fantasie sind da kaum Grenzen gesetzt und Beispiele gibt es ja genug (cPanel usw.). Ich selber habe mir eine Webseite gebaut, die Statistiken rund um meinen Webserver ausliest.
Schwierig wird es, wenn Befehle ausgeführt werden sollen, die root-Rechte benötigen. Man muss aufpassen, dass man keine Sicherheitslücken in Scheunentorgröße aufreißt!

 

[datasmurf]

Hallo,

es gibt in den Ports/Packages bspw. www/websocketd damit kann man mit ein wenig Unterstützung von w3schools's PHP/HTML Einführung, wenn man will, sicher recht fix eine WebGUI zusammenbasteln. Auch mit wenig Vorkenntnissen.

Tschö

 

[sanbiber]

Parameter parsen und wenn's geht generell nur fixe Were nutzen (also Dateien mit fixem oder vollständig vom Server generierte Namen).

Was ist "fixe Were"?
Und was verstehst Du alles als Parameter? Ist auch die Eingabedatei inkl. ihr Content ein Parameter?

Schauen, dass alle Zahlen Zahlen sind und ganz generell nichts was vom Client kommt ausführen. Im Besten Fall macht man wohl ein Form, überlegt sich eigene Namen für die Optionen und macht dann selbst einen Befehl draud.

Wobei form per se nicht sicher ist, oder? So verhindert man evtl., dass normale User falsche Eingaben machen (können), aber Bösewichte könnten auch direkt die Header manipulieren, oder?

Wenn's geht Jail, eigener User, Pledge/Unveil (damit kann man recht einfach verhindern das geforkte Software was anstellen kann), etc. verwenden.

Was sind pledge/unveil? Gibt es das für alle BSDs?

 

[sanbiber]

es gibt in den Ports/Packages bspw. www/websocketd damit kann man mit ein wenig Unterstützung von w3schools's PHP/HTML Einführung, wenn man will, sicher recht fix eine WebGUI zusammenbasteln. Auch mit wenig Vorkenntnissen.

websocketd sieht interessant aus!
Nur: wozu bräuchte ich das, wenn ich sowieso mit PHP/perl/python/... eine Webanwendung programmieren muss, die dann auch direkt system calls machen kann? Wenn Interface und Anwendung separiert auf unterschiedlichen Hosts laufen (sollen), dann kann ich mir vorstellen, dass eine Kommunikation über websockets Sinn machen könnte. Aber sonst?

 

[Andy_m4]

So verhindert man evtl., dass normale User falsche Eingaben machen (können), aber Bösewichte könnten auch direkt die Header manipulieren, oder?

Usereingaben sollten natürlich validiert werden bevor Du die an Deine Kommandozeilentools weiterreichst. Wobei das auch etwas tricky sein kann. Weil Du auch solche Fälle abfangen musst, wo jemand einfach ein Semikolon mit reinschreibt und dahinter ein rm -rf / macht oder so.

Was sind pledge/unveil? Gibt es das für alle BSDs?

Das ist eine Spezialität von OpenBSD:

https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pdf

Die Entsprechung in FreeBSD wäre eher Capsicum:

Capsicum - FreeBSD Wiki

wiki.freebsd.org

 

[Athaba]

Was ist "fixe Were"?
Und was verstehst Du alles als Parameter? Ist auch die Eingabedatei inkl. ihr Content ein Parameter?

Mit fixe Werte meine ich, dass man Parameter nicht direkt Front-End übergibt, sondern das Front-End zum Beispiel nur Keys hat die in einem Lookup-Table sind und daraus Argumente (das meine ich mit Parametern) übergeben werden.

Wobei form per se nicht sicher ist, oder? So verhindert man evtl., dass normale User falsche Eingaben machen (können), aber Bösewichte könnten auch direkt die Header manipulieren, oder?

Mir ging's darum was am Server passiert/erlaubt wird, nicht am Client.

Deshalb starke Trennung vom Form-Input. Sagen wir jetzt mal als Beispiel, ein Web-Frontend für expr, als Taschenrechner. Das ist das einfachste Beispiel, dass mir zur Erklärung schnell eingefallen ist. Aber das sollte sich auf die meisten Anwendungsfälle übertragen lassen.

Statt am Front End den Command zu machen hast du zum Beispiel ein Form mit Zahlen und Operatoren. Die Zahlen parsed man in der Programmiersprache, damit das zum Beispiel fix Integer sind. Operatoren übernimmt man nicht groß sondern macht man als Map und nur wenn so ein Map-Key matched passiert irgendwas (ansonsten nur Fehler ans Frontend). Dann kommt man nie in der Verlegenheit Input zu übergeben und auch nicht da große, komplexe Inputvalidierungen zu machen nur um irgendwas zu übersehen.

Das mit Keys mappen hat den Vorteil, dass man relativ gut den Überblick darüber behält was möglich ist. Wenn du es außerdem schaffst nur Zahlen als frei auswählbare Werte zu haben, dann könne die auch recht einfach validiert werden.

Also in dem expr Beispiel für 1 + 1 würdest du ein Form machen, wo du zwei Zahlen-Inputs hast, sagen wir A und B und einen Operator Input (sagen wir mal nur + (Value: PLUS) und - (Value: MINUS).

Das Form ist dann:
a=1
b=1
operator=PLUS

Am Backend parsed du die Form-Values A und B als Integer. Wenn eines davon kein Integer ist (also beim Parsing ein Fehler auftritt) stoppst du und lieferst einen Fehler. Den Operator vergleichst du zum Beispiel mit einer Map (Dictionary, Hash), sagen wir sowas wie {PLUS: '+', MINUS: '-'}. Wenn der Key nicht existiert stoppst du und lieferst einen Fehler. Wenn es den Eintrag gibst, nimmst du das Value und baust dann daraus ein expr $A $OPERATOR $B.

Was ich damit sagen will. Groß Parser zu schreiben um alles was schädlich sein kann, kann auf sehr, sehr viele Arten in die Hose gehen. Da kann man übersehen, dass ein Befehl irgendwo was forken kann, dass man vielleicht wo Umgebungsvariablen ausnutzen kann oder man macht einfach irgendwo einen Denkfehler oder sonst was. Wenn du alles explizit selbst ausprogrammieren musst was erlaubt ist (Maps statt Regex, oder was Argumente erlauben, etc.), dann ist die Chance zumindest deutlich kleiner da was zu übersehen. Hängt natürlich von der Mächtigkeit von dem Programmen ab, aber es ist ja so, dass wenn man meist nur ein paar Features von sagen wir mal Imagemagick haben will, Resizing zum Beispiel.

Was sind pledge/unveil? Gibt es das für alle BSDs?

Pledge/unveil sind OpenBSD-Sachen. Mit denen kannst du verhindern, dass ein Prozess (oder ein Fork davon, was hier interessanter wäre) bestimmte Dinge tun darf (Dateien modifizieren, Internet-Verbindungen aufbauen, selbst Prozesse spawnen, etc.).

Natürlich gibt's noch andere Sachen unter FreeBSD eben capsicum, wobei das dann wohl nicht direkt als Library eingesetzt werden würde, sondern in dem Fall eher mit sowas, wie capsicumizer. Ist wohl einfacher.

Und natürlich kann/sollte man als erste Schicht auch klassischeres machen. User ohne Priviligien nutzen, etc. Hängt vom Anwendungsfall was man machen kann.

Wie gesagt, mir ging's darum nicht in die Versuchung zu kommen nur was verboten ist auszuschließen, sondern die Herangehensweise zu wählen nur das zu erlauben was explizit erlaubt wird. Ich habe schon zu viele Fälle gesehen wo der erste Weg gewählt wurde und ins Verderben geführt hat.

 

[sanbiber]

Das sind sehr gute Hinweise, Danke @Athaba .

Das mit der Input-Validierung verstehe ich im Prinzip.
Allerdings wird man doch irgendwo mit den Eingabewerten direkt arbeiten müssen, oder? Also bei Deinem Ansatz (key-value-map) wird man irgendwann einen lookup mit der Original-Eingabe machen müssen, etwa (Pseudocode):

if $INPUT in $MAP then
  CODE
end if

Ist da nicht eine Eingabe denkbar, die die Prüfung z.B. aushebelt (z.B. hier für $INPUT 1 == 1 or "X")?


Bei dem, was mir vorschwebt, kommt erschwerend hinzu, dass eine Datei hochgeladen werden soll, die dann verarbeitet wird. Da kann ich sicher einschränken, dass sie nicht zu groß ist und dass sie nicht einen schädlichen Dateinamen hat. Aber ich kann jetzt nicht - ohne erheblichen Aufwand - schauen, ob sie validen Content hat. Oder doch?

 

[juedan]

Nicht, wenn Du es so machst:

if $INPUT in $MAP then
 CODE
else
 hinweis;
 exit;
end if;

 

[juedan]

Nachtrag zu meinem Posting:
Baue ein Berechtigungssytem auf: "echte Admins" bekommen vollen Zugriff auf alle Parameter eines Komandos, "normale User" dürfen nur bestimmte Parameter nutzen, die fest kodiert sind. Alle Admins und User werden von Dir persönlich in eine (Datenbank-)Tabelle eingetragen.
Beispiel:
echter Admin darf ein "gpart add bla, bla" ausführen
normaler User darf nur "gpart show ada0" ausführen und das steht so im Code drin:

execute "gpart show ada0"

Der Vorteil dieser aufwendigen Methode ist, dass Du ruhiger schlafen kannst.

Schönen vierten Advent noch

 

[sanbiber]

Auch n spannender Ansatz mit dem Berechtigungssystem, @juedan . Für meine Zwecke aus jetziger Sicht allerdings overkill. Was an Deinem Code das Gegenbeispiel sein soll, verstehe ich nicht. @Athaba meinte ja, dass man nie Benutzereingaben direkt verarbeiten sollte und hat als Lösung vorgeschlagen, eine Menge an zugelassenen Werten (key-map) zu definieren und dann nachzuschauen, ob die Eingabe in der Menge enthalten ist. Da war meine Vermutung, dass man an irgendeiner Stelle, eben z.B. beim lookup doch direkt mit der Eingabe wird arbeiten müssen. Mein Beispiel war dann (ähnlich wie z.B. bei einer SQL injection), dass eine böswillige Eingabe den Zutritt in einen Code-Bereich ermöglichen könnte, in den man eigentlich nicht kommen dürfte, weil es eben eine nicht zulässige Eingabe sein sollte, eine, die auch z.B. nicht in der key-Map ist. Bei Deinem Beispiel, @juedan kann ich doch immer noch mit einer böswilligen Eingabe, die nicht in der MAP ist, in den CODE-Bereich kommen ... Oder verstehe ich das falsch?

 

[juedan]

Hallo sanbiber,

Mein Beispiel war dann (ähnlich wie z.B. bei einer SQL injection), dass eine böswillige Eingabe den Zutritt in einen Code-Bereich ermöglichen könnte, in den man eigentlich nicht kommen dürfte, weil es eben eine nicht zulässige Eingabe sein sollte, eine, die auch z.B. nicht in der key-Map ist. Bei Deinem Beispiel, @juedan kann ich doch immer noch mit einer böswilligen Eingabe, die nicht in der MAP ist, in den CODE-Bereich kommen ... Oder verstehe ich das falsch?

Ich hoffe nicht, dass wir aneinander vorbeireden
Mein Code-Beispiel sagt aus, wenn $INPUT in $MAP enthalten ist, dann führe den Code CODE aus. Falls nicht (else), dann schreibe einen Hinweis (hinweis) und beende das Programm (exit). Es ist das gleiche wie bei dir, bloß etwas mitteilsamer.
Es kann im Grunde nichts passieren, wenn Du $MAP sinnvoll und korrekt definierst.

Bei meiner Homepage mache ich es so:
Es gibt eine Seite, die nennt sich wetterdienst_karte.php. Sie stellt alle möglichen Wetterinformationskarten dar. In einem Array habe ich definiert, welche Arten von Wetterkarten es gibt:

$kartentyp = array("unwetter" => "Wetterwarnung", "wetterdaten" => "Wetterkarte", "niederschlagsradar" => "Radarkarten", "mesozyklonen" => "Mesozyklonen", ...);

Prüfung, ob ein korrekter Kartentyp aufgerufen wird:

if (array_key_exists($typ, $kartentyp)) {
 Wetterkarte_darstellen($typ);
else
 Hinweis("Dieser Kartentyp existiert nicht");

Korrekt Aufgerufen wird die Seite mit .../wetterdienst_karte.php?typ=unwetter
Nicht korrekt wäre .../wetterdienst_karte.php?typ=sauwetter ; es käme der Hinweis "Dieser Kartentyp existiert nicht"

 

[Athaba]

Ist da nicht eine Eingabe denkbar, die die Prüfung z.B. aushebelt (z.B. hier für $INPUT 1 == 1 or "X")?

Deshalb immer den "wenn kein Match -> Error". Am Besten ist wie juedan, immer gleich ein Else zu haben, dann kannst du schnell drüberschauen, ob alles einen Else-Error-Zweig hat (also generell, auch Fälle von denen du sagen würdest "Das kann nie passieren").


Wichtig ist, dass da nicht nur geloggt wird sondern dort auf irgendeine Art und Weise abgebrochen wird, je nachdem wie der Code strukturiert ist mit Fehler zurückgeben oder mit Error Thrown/zurückgeben, was dann von der äußeren Funktion abgefangen wird. Hängt davon ab was im Framework/Lib/Sprache/Struktur der richtige Weg ist.

 

[sanbiber]

Bei meiner Homepage mache ich es so:
...

$kartentyp = array("unwetter" => "Wetterwarnung", "wetterdaten" => "Wetterkarte", "niederschlagsradar" => "Radarkarten", "mesozyklonen" => "Mesozyklonen", ...);

Prüfung, ob ein korrekter Kartentyp aufgerufen wird:

if (array_key_exists($typ, $kartentyp)) {
Wetterkarte_darstellen($typ);
else
Hinweis("Dieser Kartentyp existiert nicht");

Korrekt Aufgerufen wird die Seite mit .../wetterdienst_karte.php?typ=unwetter

und hier wär mein Bsp:

$typ = "'', ['']) or ($kartentyp =="

Wenn $typ nun eins-zu-1 eingesetzt werden würde, dann käme man immer in den Wetterkarte_darstellen-Zweig.