Oldperl hat geschrieben:Wieso besser?
einfach weil sicherer. und in der pflege vermutlich auch einfacher. denn um diese zwei dinge geht es ja vermutlich. rein kommen ohne login = komfort, und aussen vor, wer nicht rein gehört = sicherheit. dieselbe baustelle, anderes werkzeug. ip-ranges zuzulassen ist nicht wirklich sicher. zumal man nur technisch einschränkt und spezifische nutzer damit nicht erfasst. im einzelfall kann es freilich durchaus sinnvoll sein. meist wird es allerdings nur eine der hürden sein.
Oldperl hat geschrieben:Gefragt war doch eigentlich bestimmte IP-Bereiche zuzulassen (also eigentlich gar keine IP-Sperre im klassischen Sinn).
was bei genauerer betrachtung dasselbe ist. aus der bekanntermassen endlichen menge an ip-adressen wenige zuzulassen bedeutet nichts anderes, als die anderen zu sperren. und klar: nur für bestimmte url-muster.
Oldperl hat geschrieben:Diese Info ist hier aber offensichtlich nicht vorhanden bzw. nicht gefragt
freundlich wie immer...
![Wink ;-)](./images/smilies/icon_wink.gif)
gefragt war eine lösung für die formulierte anforderung. nach der reinen lehre (deren anwendung eben durchaus sinn macht), muss man zunächst die anforderungen von impliziten technischen spezifikationen trennen. was dann bleibt ist eine cug ohne login. brainstorming (yep, genau das war gefragt) funktioniert ohne scheuklappen im allgemeinen deutlich besser.
Oldperl hat geschrieben:Jedoch müßte man entsprechend Anpassungen vornehmen wenn sich z.B. Kategorien ändern oder hinzukommen.
hängt halt vom konzept ab. man kann durchaus bestimmte urlmuster abfangen. liegen kategorien innerhalb bestimmter kategorien greift die sperre. das ist ein valables und verbreites verfahren. immerhin ist typischerweise die url vom dateisystem entkoppelt, weshalb man aus der url nicht zwingend ableiten muss (mindestens nicht aus der vollständigen), wo die abarbeitung erfolgt. bei einem cms wird sie ohnehin weitergereicht.
Oldperl hat geschrieben:Auch ein zusätzliches Anzeigen bei vorhandenem FE-User (eingeloggt) aber nicht übereinstimmendem IP-Bereich wäre problematisch.
nicht unlösbar, denke ich mal. denn schützen könnte man die seiten trotzdem. und die url müsste ja - für die zwar gleiche seite - nicht notwendigerweise dieselbe sein. aber letztlich ist natürlich die annahme einer rolle aufgrund anderer kriterien als einem login durchaus sinnvoll. denkbar ist auch, die umleitung bei übereinstimmender ip nicht mehr auf front_content.php, sondern auf ein anderes skript umzulenken, welches einfach eine bestimmte rolle setzt und anschliessend die front_content.php inkludiert. oder ähnlich. oder eben über die cec abfrühstücken. wird wohl abhängig sein von den skills und dem knoff-hoff in der conti-welt.