Verzeichnisschutz

[thueske]

Bezieht sich dein Feature-Request auf ein zugrundeliegendes Problem? Bitte beschreibe es uns: Ich möchte meine Entwicklungsumgebungen vor unberechtigtem Zugriff sperren.

Beschreibe die Lösung(en), die du dir vorstellen könntest: Die Erstellung eines .htaccess-Passwortschutzes könnte automatisiert über das mStudio angeboten werden.

[maixithn]

eine Einrichtung von geschützten Verzeichnissen auf Anwenderebene fände ich auch wünschenswert, zusätzlich könnte auch htpasswd in der cli weiterhelfen (falls es schon vergleichbare Kommandos verfügbar sind bitte mitteilen)

[steffen-hph]

Da es aktuell vermutlich nicht beabsichtigt ist, dass die Passwort-Sicherheit des definierten Passworts im Kundencenter nicht korrekt geprüft wird, wollte ich das hier auch einmal anbringen, dass dieser Bug (bzw. für uns Feature) gut ist. Manchmal möchte man einfach irgendein einfaches Passwort, was man mal eben per Telefon weitersagen kann. Das schützt dann z.B. nur vor Suchmaschinen Indizierung. Also vielleicht mit lediglich einem Hinweis auf die Passwort-Sicherheit bzw. Unsicherheit?!

[lmrkavogt]

Manchmal möchte man einfach irgendein einfaches Passwort, was man mal eben per Telefon weitersagen kann.

Ich nutz dafür eine eigene PasteBin-Installation: https://paste.lmrk.app/ Damit gibts dann auf jeden Fall keine Datenschutz-Probleme

[patrickhilker]

zusätzlich könnte auch htpasswd in der cli weiterhelfen

@maixithn u.a. htpasswd steht jetzt bereit (im Cluster "Fiestel" erfolgt der Rollout nach und nach und dauert ggf. noch ein wenig - falls es dringend schneller gehen muss, hilft eine Veränderung in der Software der App).

[maixithn]

Wir freuen uns sehr über die angekündigte Lieferung … Grüße aus Fabbenstedt ;)

[holmey]

Darf ich fragen wie die Implementierung hier genau aussieht? Wird es so sein, dass es dann eine komfortable Lösung geben wird, die .htaccess im Projekt anzupassen? Uns würde der Verzeichnisschutz tatsächlich auf einer andern Ebene weiterhelfen. Da wir hier mit Apache arbeiten, ist die .htaccess Teil unserer Applikationen, die wir dann auch entsprechend in unsere Projekt-Repositories nutzen (z.B. Redirects, deflate, ...) und einpflegen. Ich denke es wäre praktisch den Verzeichnisschutz irgendwie vorzulagern, um so die Anwendung von der Deployment Umgebung zu trennen. Ich gebe ein Beispiel: Setzen wir eine .htaccess auf Anwendungseben ein muss jeder Entwickler, der das Projekt lokal installiert, das Passwort kennen und eingeben. Noch ein Beispiel: Wir haben die gleiche Anwendung als Stage und Prod App bei euch abgelegt. Die eine Umgebung benötigt Basic Auth die andere nicht.

[maixithn]

htpasswd ist jetzt verfügbar, danke! Das erleichtert die schnelle Einrichtung sehr …

eine (mögliche) Umsetzung über die Serverkonfiguration wäre wünschenswert, sodass technische Laien das Feature verwenden können und man sich nicht ins Gehege kommt, wenn über htaccess andere Directiven eingesetzt werden wie oben beschrieben

[patrickhilker]

[..] Wird es so sein, dass es dann eine komfortable Lösung geben wird, die .htaccess im Projekt anzupassen? Uns würde der Verzeichnisschutz tatsächlich auf einer andern Ebene weiterhelfen. [..]

Wie genau unsere Lösung aussieht, kann ich heute noch nicht verlässlich beantworten. Mir schwebt aber tatsächlich auch vor, dass wir irgendwie die mStudio-User automatisch integriert bekommen - möglicherweise könnte man den Zugriff dann sogar an die Rolle hängen.

Zusätzlich müssen natürlich auch andere User funktionieren - schließlich ist nicht jeder Kunde, der möglicherweise auf ein Preview-System zugreifen soll, auch automatisch im mStudio registriert.

Einfach in irgendwelchen Projekt-Dateien herumrühren möchte ich eigentlich ungern, denn, - wie du schon schreibst - das sind eure Dateien. Wir haben eh Reverse Proxys vor den Projekt-Webservern, sodass es sich möglicherweise anbieten könnte, das da zu handlen.

[maixithn]

die Integration der mStudio-User finde ich eine sehr gute Idee, die Registrierung von Projektpartnern finde ich zumutbar, wenn nicht sogar wünschenswert: dann könnte man sie auch direkt einladen ;)

[holmey]

In Netlify hat man z.B ganz einfach die Möglichkeit pro "App" ein Passwort zu vergeben. Viel komplexer müsste es für uns gar nicht sein. Super wäre es natürlich, wenn man mehr als eine Benutzername/Passwort angeben könnte.

Eine andere Idee: Theoretisch könnten wir auch auf sehr technischer Ebene denken, denn es geht uns eher um das Herauslösen des Features Passwortschutz, aus dem Applikationscode, als um eine komfortable Möglichkeit diesen Login anzulegen. Wenn man z.B. übergreifend Header konfigurieren könnte (eventuell aus anderen Gründen auch praktisch) wäre es auch einfach möglich Header wie folgt zu definieren: https://github.com/orgs/vercel/discussions/2920 Wo ich drüber nachdenke: Kann man in .htaccess Dateien auch auf Environment Variablen reagieren?

[pf-iservice]

In Shopware und auch bei einem anderen Provider schätze ich den Zugriff per IP-Adresse sehr. So muss ich bei Arbeits-Installationen die nicht öffentlich sein sollen nicht Login-PW eingeben. Shopware hat das z.B. bei der Angabe des Wartungsmodus super elegant gelöst. Neben der manuellen Eingabe von IPs wird bei Anklicken des Felds sofort die aktive IP-Adresse angezeigt und kann mit einem Klick in das Eingabefeld übernommen werden.

[patrickhilker]

Spannender Ansatz, vielen Dank! Wo würdet ihr so eine Einstellung (IP-Beschränkung, Passwort, ...) als erstes suchen? In der App? In der Domain? Meine Tendenz geht klar zur App.

[holmey]

Wäre für mich ganz klar auf der Ebene der App und auch da ggf. nur optional, denn wenigstens in der Theorie müsste für mich eine App gar keine Verbindung nach aussen bereitstellen.

[pf-iservice]

Denke schon in der App. Zuerst Auswahl des Verzeichnisses und anschließend die Eigenschaften eingeben. Evtl. mit Select-Box on/off.

Oder, sofern es zukünftig einen File-Manager gibt, direkt bei "Eigenschaften eines Verzeichnisses". ;-) Im Dateibaum könnte man ein geschütztes Verzeichnis optisch kennzeichnen. Evtl. kann man so auch sFTP-Uploads von Servern externer Systeme zusätzlich absichern.