> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. **Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde.** Beispiel? Der Newsfeed so mancher großer Zeitung selbst. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Sogar mit der Überschrift *"Hier Überschrift einfügen"*. Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Der Link zu dem eigentlich gesperrten Artikel wird dann z.B. [auch noch über solche Seiten veröffentlicht](https://www.fastix.org/news.php). Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. [Man kann es aber auch gleich "groß" machen](https://code.fastix.org/Projekte/PHP%3Alogin-system/). Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html). Oder der Verwalter eines Proxy-Servers veröffentlicht diese "geheimen" URLs in Statistiken, weil die ja für ihn nicht "geheim" sind. Man verliert jegliche Kontrolle.

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. **Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde.** Beispiel? Der Newsfeed so mancher großer Zeitung selbst. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Sogar mit der Überschrift *"Hier Überschrift einfügen"*. Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Der Link zu dem eigentlich gesperrten Artikel wird dann z.B. [auch noch über solche Seiten veröffentlicht](https://www.fastix.org/news.php). Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. [Man kann es aber auch gleich "groß" machen](https://code.fastix.org/Projekte/PHP%3Alogin-system/). Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html). Oder der Verwalter eines Proxy-Servers veröffentlicht diese "geheimen" URLs in Statistiken, weil die ja für ihn nicht "geheim" sind.

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. **Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde.** Beispiel? Der Newsfeed so mancher großer Zeitung selbst. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Sogar mit der Überschrift *"Hier Überschrift einfügen"*. Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Der Link zu dem eigentlich gesperrten Artikel wird dann z.B. [auch noch über solche Seiten veröffentlicht](https://www.fastix.org/news.php). Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. [Man kann es aber auch gleich "groß" machen](https://code.fastix.org/Projekte/PHP%3Alogin-system/). Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html). Oder der Verwalter eines Proxy-Servers veröffentlicht diese "geheimen" URLs in Statistiken, weil die ja für ihn nicht "geheim" sind.

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. **Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde.** Beispiel? Der Newsfeed so mancher großer Zeitung selbst. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Sogar mit der Überschrift *"Hier Überschrift einfügen"*. Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. [Man kann es aber auch gleich "groß" machen](https://code.fastix.org/Projekte/PHP%3Alogin-system/). Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde. Beispiel? Der Newsfeed so mancher großer Zeitung. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Sogar mit der Überschrift *"Hier Überschrift einfügen"*. Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. [Man kann es aber auch gleich "groß" machen](https://code.fastix.org/Projekte/PHP%3Alogin-system/). Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde. Beispiel? Der Newsfeed so mancher großer Zeitung. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Oder mit der Überschrift "Hier Überschrift einfügen". Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. [Man kann es aber auch gleich "groß" machen](https://code.fastix.org/Projekte/PHP%3Alogin-system/). Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde. Beispiel? Der Newsfeed so mancher großer Zeitung. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Oder mit der Überschrift "Hier Überschrift einfügen". Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. [Man kann es aber auch gleich "groß" machen](https://code.fastix.org/Projekte/PHP%3Alogin-system/). Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde. Beispiel? Der Newsfeed so mancher großer Zeitung. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Oder mit der Überschrift "Hier Überschrift einfügen". Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: **Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*.** Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde. Beispiel? Der Newsfeed so mancher großer Zeitung. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Oder mit der Überschrift "Hier Überschrift einfügen". Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*. Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde. Beispiel? Der Newsfeed so mancher großer Zeitung. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Oder mit der Überschrift "Hier Überschrift einfügen". Mithin hält sich deren Feedgenerator nicht an die Rechteverwaltung, funktioniert also nur scheinbar. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*. Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).

> Wie gesagt, bei Kleinprojekt, durchaus vertretbar. Ich möchte nicht gar nicht wissen wie viele Datenlecks in die Zeitung gekommen sind, weil diese als Kleinprojekt begannen und dann das Provisorium (aus welchem Grund auch immer) beibehalten wurde. Beispiel? Der Newsfeed so mancher großer Zeitung. Da finden sich oft Artikel - mit dem Sperrhinweis, diese erst um 20:00 freizugeben. Oder mit der Überschrift "Hier Überschrift einfügen". Mithin funktioniert hält sich deren Feedgenerator nicht an die Rechteverwaltung. Das ist zwar scheinbar ein ganz anderes Problem - hat aber die selbe Ursache: Irgend jemand denkt sich: *"bei Kleinprojekt, durchaus vertretbar"*. Zudem wäre vorliegend die [Zugriffsbeschränkung mit dem Mitteln des Webservers](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) durchaus anwend- und vertretbar. [Eine solche Lösung](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/) kann man dann auch noch so anpassen, dass die Benutzer ein automatisch erzeugtes Passwort per Mail bekommen und bei Nichtzahlung (vorläufig) gesperrt statt gelöscht werden. Auch eine Umstellung auf eine Datenbank e.t.c. ist kein Problem, weil ohne Seiteneffekte. Die "Geheimen Links" müsste man nämlich auch verwalten und entweder individuell generieren (und also verwalten) oder jedem erlaubten Benutzer bei jeder Änderung des Nutzerkreises den neuen "Geheimen Links" zusenden. Ersteres verursacht den gleichen Aufwand wie die Zugriffsbeschränkung per htaccess, letzteres führt ganz schnell zu ziemlich unzufriedenen Kunden, die dann nämlich dauernd die Favoriten anpassen müssen. Und, wie gesagt, [solche "geheimen Links" geraten regelmäßig in die "Wildbahn" oder werden "erraten"](https://www.heise.de/newsticker/meldung/Datenleck-bei-Domainfactory-Hacker-knackt-Systeme-laesst-Kundendaten-mitgehen-4102881.html).