Mobirise-Tutorials.com

Zum Thema Sicherheit :

ich könnte auch hier in diesem Script ein kleines Script einbauen, welches mit einem cronjob jeden Tag (auch mehrmals) die daten.json sichert in einem Verzeichnis an das nur Ich ran komme.

Dann könnte der böse Tommy alles löschen, Seiten, User, Admins und alles wäre mir Pups Egal, weil ich den Stand von heute Nacht 3 Uhr wieder einspiele und den Tommy raus schmeiße

Aber ich will jetzt auch nicht übertreiben und das einbauen - könnte ich aber

Du - ich sage nur meine Meinung. Mache es wie Du denkst aber sage den Leuten es dann auch so.

Ich habe das nur mal zum Gucken ausprobiert, denn ich habe für das Skript keine Verwendung, wie ich bereits Anfangs erwähnt habe.

Ich kenne keine Anwendungen bei denne der Inhaber durch einen anderen Admin bearbeitet werden könnte. Weder von Werner, noch von diesem Forum, noch von PHPJabbers und auch nicht von einer KI.

... bin jetzt mal eine Weile weg. Heute ist Berlin-Marathon mit 80.000 Läufern.

Ich werde das natürlich erwähnen das wenn man einem User Admin Rechte gibt, der alles auch löschen kann und es so zu Ausfall des Scriptes, bzw. der Webseite führen könnte, weil eben kein EInloggen möglich und die Seiten nicht aufrufbar sind.

Aber ich betone es noch mal : Man muss ja keinen 2. Admin haben Dann kann auch kein User irgend etwas ändern.

In meiner Beispiel Seite gibt es 2 Admins, aus dem einfachen Grund, weil der Admin sich selber keine Seiten zuweisen kann, benötigt man einen 2. Admin der dem Admin Seiten zuweist die er im Dashboard eingeblendet bekommt.

Es fehlt einfach im Script die Möglichkeit sich selber zu editieren. Das habe ich schlicht vergessen und somit das über einen 2. Admin geregelt. Dieser 2. Admin bin ich ja auch selber.

Wer einem Fremden oder Freund zum Admin macht, hat eben das Risiko, das der aus versehen, oder bewusst Dinge löscht oder ändert und somit die Seite nicht mehr richtig läuft, weil eben User sich nicht mehr anmelden können oder Seiten nicht aufgeführt werden.

Ich glaube das hat jetzt auch jeder verstanden

Man kann natürlich auch nur einen Admin haben. Der kann allerdings in seinem Dashboard dann keine Seiten sehen. Ist auch nicht erforderlich, da er die ja selber in Mobirise erstellt hat Nur dafür ist der 2. Admin gedacht, dem Admin die Seiten zuzuweisen !!!

Man könnte es auch einen Bug nennen

Aber ich mache da jetzt nicht mehr an dem Script, weil ich denke jeder der hier mit gelesen hat weiß nun worum es geht und wie es gehandelt werden kann.

Zum Thema Schutz der .json mit htaccess:

Wenn jemand die daten.json in daten.JSON oder anders umbenennen sollte wird das ganze Script nicht mehr laufen.
Das Script erwartet eine daten.json und liest nur diese aus. Eine Änderung der Endung in Großbuchstaben wäre also Quatsch und macht das Script unbrauchbar. Also ist die beigelegte htaccess vollkommend ausreichend um die json vor Aufruf zu schützen.

Nachdem ich mir gerade Dein Video angesehen habe, habe ich mal noch folgende Frage (das hatte ich vorhin so nicht ausprobiert).

Nehmen wir an, ich habe mein drei Jahre altes Mobirise-Projekt und hatte bereits eine Seite "gastbuch.php" für mein Gästebuch vor 3 Jahren erstellt, das natürlich öffentlich zugänglich sein soll und eben von allen zu sehen sein soll, genau wie auch vorher.

Wird diese Seite dann automatisch durch Deine Anwendung gesperrt und nur für diejenige User nutzbar, die registriert und eingeloggt sind?

... so sah das in Deinem Video für mich gerade aus

Ich denke das diese Gästebuchseite erst dann gesperrt würde, wenn man den deren Dateinamen "gastbuch.php" mit in die Administrator-Verwaltung aufnimmt. Habe ich das richtig verstanden. Du sprichst immer von "erstellen", man erstellt noch nix in Deinem Skript, die Seiten werden doch einzig und alleine von Mobirise erstellt.

Wenn dein GB eine .json im root hat, dann wird die durch die htaccess auch gesperrt. Richtig !
Falls Du das meinst

Wenn das der Fall wäre, dann muss die daten.json in ein separates Verzeichnis gelegt werden, mit der htaccess und es müssen eben in den PHP Scripten die Pfade entsprechend geändert werden.

Oder aber du legts das GB in ein anderes Verzeichnis - wäre ja auch möglich

Es werden nur Seiten gesperrt die den Session Aufruf haben den ich gepostet habe. Sonst wird da nichts gesperrt.

sorry - aber das halte ich für restlos inakzeptabel

Mit meinen bereits vorhandenen PHP-Seiten und dem Aufbau meines Projektes darf nichts passieren aber auch gar nichts, solange ich deise nicht nachträglich sperre.

Tommy Herrmann hat geschrieben: So 21. Sep 2025, 13:11
Habe ich das richtig verstanden. Du sprichst immer von "erstellen", man erstellt noch nix in Deinem Skript, die Seiten werden doch einzig und alleine von Mobirise erstellt.

Genau Tommy, die werden in Mobirse erstellt, aber das Script muss doch auch genau diese Seiten kennen. Also muss man die dort eintragen, sonst klappt das doch nicht.

Tommy Herrmann hat geschrieben: So 21. Sep 2025, 13:21 sorry - aber das halte ich für restlos inakzeptabel

Mit meinen bereits vorhandenen PHP-Seiten und dem Aufbau meines Projektes darf nichts passieren aber auch gar nichts.

Ich sagte doch bereits, wenn es im Root .json gibt, dann würde es mit der htaccess Regel Probleme geben. Die kann man doch umgehen, in dem man die daten.json woanders rein legt. Verstehe die Aufregung gerade nicht

das ist keine Aufregung - das muss bereits so ausgeliefert werden. Das ist sonst niemandem zuzumuten.

Ich sagte in meinem Video explizit: Legt das in ein Verzeichnis auf euren Server und testet es .

Wer seine Webseite im Root hat und dieses Script verwenden will, muss wenn er .json im Root hat eben entsprechend handeln. Aber ich denke das sollte doch klar sein, wenn ich den Zugriff auf .json unterbinde.

Aber auch nur wenn diese .json abgefrufen werden soll im browser, nicht durch ein script. Auch ein Unterschied. Also keine Panik verbreiten bitte

Mein Script greift doch auch auf die json zu. Nur keiner kann an die ran von außen !

ich hab mal in meinem GB die htaccess raus genommen:

https://www.niederastroth.de/gbtest/entries.json

DAS Passiert wenn man es nicht schützt. Ist der Schutz aktiv kann da keiner rein schauen. DAS ist das was ich meine Tommy und was absolut Richtig ist !

Also kein Grund zur Panik und miesmache

Scripte greifen nach wie vor auf die json zu und geben das dann auch in HTML aus. SO wie es sein muss.

Und wie ich sehe hast Du das auch nicht geschützt

Link entfernt

Auch da sollte eine htaccess rein um den Aufruf von außen zu verhindern. DAs ist aber bei allen Daten so, egal ob das eine .json, oder txt oder sonst was ist.

OK, ich hätte das vorher erwähnen müssen, aber ich denke eben auch das User das wissen sollten die Daten auf einem öffentlichen Webserver haben die auch zu Schützen wissen.

Ich kann doch nicht für alle mitdenken.

Da nutzt das verstecken der E-Mails auch nichts

Schau mal selber, ich hab den Link wieder raus genommen. Sicherheitshalber

Keine Ahnung was da falsch war - ich hatte die .htaccess drinnen - sie ging nicht, habe dies nun überschrieben.

Die .htaccess sollte aber bei allen zu schützenden Daten auch immer gleich mit im Download dabei sein. Auch wenn man das weiß, kann man es sonst schnell mal vergessen.

Tommy,
im Prinzip hast Du Recht. Aber ich baue PHP Scripte die auch auf Servern mit Windows, oder NGINX nutzbar sind.
Da wirkt keine htaccess, da muss man das anders schützen.

Aber ganz ehrlich ? Das muss doch ein Webseiten / Server Besitzer wissen, das man sensible Daten da schützen muss.
Ich kann das gerne immer wieder erwähnen, aber sicher nicht für alle Servertypen direkt in den Download legen.


Für einen NGINX muss das ganze so aussehen:

server {
listen 80;
server_name deine-domain.tld;

root /var/www/html;

index index.php index.html index.htm;

# Zugriff auf sensible Dateien sperren
location ~ \.(json|ini|log|env)$ {
deny all;
return 403;
}

# PHP-Dateien (falls PHP-FPM genutzt wird)
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}

# Statische Dateien normal ausliefern
location / {
try_files $uri $uri/ =404;
}
}