Moin,
jow, also zusammengefasst: Das was ich will gibt es nicht ;)
euere Ideen hab ich mir mal angeschaut...
also auth-provider selbst schreiben fällt für mich leider aus.
weder kann ich lua, noch hab ich die zeit mich da einzuarbeiten...
rewrite mit dbd klingt verlockend, nur könnte die performance nicht so toll werden wenn bei jedem zugriff auf die db zugegriffen wird.
es gibt zwar ein "fastdbd", nur "it won't pick up on changes to the database until the server is restarted"
per script ein htaccess zu erzeugen ist wohl derzeit die vielversprechenste Lösung.
"require ip" ist etwas, dass bereits existiert und in funktion und performance gut in der freien wildbahn getestet ist... ;)
Danke für euere Ideen,
Viele Grüße
Norman
Oliver Rompcik <oliver@???> schrieb am Sa, 11. Feb 01:17:
> 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!
>
--
Norman "bigboss" Zimmer
GnuPG-ID: 0x1842A431
Packets don't lie, but they may not tell everything if captured by a misconfigured filter.
--
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)