Am 10.02.23 um 15:49 schrieb Sven Velt:
> Hio!
>
> On 10.02.23 14:01, Oliver Rompcik wrote:
>> Eine einfache Lösung, wenn sich die DB nicht sekündlich ändert:
>> Generiere per Script periodisch (z.B. alle 5 Minuten) aus der DB eine
>> .htaccess...
>
> ... und vermutlich verbraucht man gesamt dann sogar weniger
> CPU-Zyklen, als wenn man jedes Mal die DB fragt. Aber das trau' ich
> mich nicht zu erwähnen, wenn jemand gleich mit DB kommt 😆
>
>> Ansonsten bleibt Dir nur, einen eigenen Auth Provider zu schreiben,
>> wie Sven schon gesagt hat. Aber ob das so "fix" geht...? Für Sven
>> vielleicht :-)
>
> Awas! Lua ist so kompliziert jetzt auch nicht! 🙃
>
Nee, das meine ich auch nicht, aber Zeit verbraucht so eine Lösung schon:
Wenn ich ein einfaches Python-, Perl- oder von mir auch aus PHP- oder
sonstwas Script baue, daß per Cron gefeuert wird, ist es klar, daß ich
hier eine lokale Lösung habe, die nur hier ganz speziell funktioniert.
Und so einfach und schnell lässt sie sich die Lösung auch bauen. Da
nehme ich dann die Sprache, die ich am besten kann. Ich nehme mal an,
auch ich habe so ein Script in 1-2h mit Tests fertig (bei mir natürlich
in Python), wenn ich die Umgebung und die DB kenne.
Aber wenn ich anfange, einen Auth-Provider für Apache in LUA zu bauen,
sieht die Kiste für mich schon mal ganz anders aus. Erst mal muss ich
mir LUA anschauen, dann die ganze Doku zu "mod_lua" inkl. der Hooks,
Datenstrukturen, Funktionen etc. und dazu muss einige Beispiele
durchgehen und die auch ausprobieren. Dabei vergeht ja schon mal Zeit.
Ich würde einfach mal so annehmen, daß ich für die Einarbeitung in LUA
und die Sichtung (mit grundlegendem Verständnis) der ganzen mod_lua-Doku
so 1-2 Arbeitstage bräuchte. Das ist meinem Empfinden nach etwas Abeits
von "fix". (Bin aber natürlich auch nicht mehr der jüngste und
schnellste und kann bisher auch kein LUA...)
Aber nun kommt das Entscheidene: Wenn ich einen solchen Auth Provider
baue, soll der ja dann möglichst variabel, weil wiederverwendbar sein.
Und da kommen dann Fragen dazu, wie: welche DBs will ich unterstützen -
schließlich unterscheiden sich z.B. MySQL und PostgreSQL grundlegend,
wie IPs gespeichert werden können: PostgreSQL hat für IPV4 und IPV6 die
Datentypen "INET" und "CIDR" (für IP-Adressen und Netzwerk-Adressen),
MySQL kennt die aber nicht. In MySQL kann man IPV4-Host-Adressen in
"UNSIGNED INT" per INET_ATON/INET_NTOA speichern und abrufen, aber keine
Netzwerkadressen und schon gar kein IPv6. SQLITE kennt noch nicht mal
INET_ATON/INET_NTOA. D.h. man muss mit Sonderlösungen auf Scriptseite
behelfen. Im schimmsten Fall speichert man die als VARCHAR und vergisst
damit auch die Prüfung der DB auf Datenvalidität, dann muss ich
zusätzliche Prüfungen im Code vornehmen, je nach DB.
Dazu kommt noch, daß ich folgende Fälle haben kann:
1. ) Alle Hosts sind verboten, bis auf die in der Liste, also ein
"Require all denied" gefolgt von einzelnen "Require ip x.y.z"
2. ) Alle Hosts sind erlaubt, bis auf die in der Liste, also ein
"Require all granted" gefolgt von einzelnen "Require not ip x.y.z"
3. ) Gemischte Liste ohne einführende Regel, also "Require ip x.y.z"
gefolgt von "Require not ip x.y.z" (oder umgekehrt)
Dabei ist jeweils zu beachten, daß es sich bei den IPs sowohl um
Einzel-, als auch Netzwerk-Adressen handeln kann (heweils durchaus
anders in der DB gespeichert).
Heißt: Code muss selber eine Config parsen.
Da schreibe ich mit Tests schon eine gewisse Zeit dran, auf jeden Fall
einiges länger als bei dem lokalen Script. Und bei mir wäre das eben
nicht mehr "fix". Kann sich aber natürlich lohnen, die Arbeit zu
investieren, wenn ich die Lösung variabel weiterverwenden kann. Mein
Ansatz war immer: Wenn Du das öfter als ein bis zwei mal brauchst, bau
es variabel, ansonsten nicht. Muss man halt im Einzelfall betrachten.
Gruß
Olli
--
Mailing-Liste der Linux User Schwabach (LUSC) e.V.
Vor und beim Posten bitte
=> http://lusc.de/List-Netiquette <= und
=> http://lusc.de/List-Howto <= beachten. Danke!
(text/plain)