Automatischer Upload (von modifizierten Dateien) auf Webserver

[Hauzuruck]

Hallo zusammen,

auf zwei PCs, die über ownCloud synchronisiert werden, entwickle ich eine Webseite. Nun würde ich gerne die modifizierten Dateien automatisch auf meinen Webspace laden lassen, damit ich sie auch online ohne einen dieser PCs anschauen kann. Ich möchte gerne von einem dritten PC die aktuelle Version betrachten.

Mir ist natürlich bewusst, dass die Daten schon in der ownCloud liegen, dort werden die PHP Dateien allerdings nicht ausgeführt, sprich die Webseite kann ich von dort nicht anschauen.

Bei der Suche nach einer Lösung fand ich z.B. das Windows-Programm ftp. Hier fand ich jedoch nicht die Option nur modifizierte Daten zu übertragen.

Vielen Dank

 

[benneq]

Normalerweise nimmt man für sowas git.

 

[M4ttX]

Z.B. Mittels Filezilla über FTP (und Versionierung über Git).

 

[MisC]

Sofern es vom Webspace unterstützt wird rsync.
Alternativ bieten auch diverse IDEs entsprechende Deloy Funktionen die einen Abgleich mit dem Webspace durchführen.
Von Git auf dem Webspace rate ich dringendst ab. Ist zwar super bequem kann aber ein Sicherheitsproblem werden wenn man ".git" nicht absichert oder es bei einem Anbieterwechsel vergisst die Absicherung zu überprüfen.

 

[snaxilian]

Code gehört in ein dafür vorgesehenes Versionierungstool > git. Wenn du nicht selbst hosten willst oder kannst kannst zu den Platzhirschen github oder gitlab geben oder andere Anbieter suchen.

Darauf basierend kann z.B. wenn neuer Code dort hochgeladen wird, eine CI/CD Pipeline starten und den Code auf einen Webserver schieben. Im einfachsten Fall wären dies z.B. bei github die Webhooks. Anleitungen findet man zuhauf wenn man beispielsweise nach "deploy php files to webspace with github hooks" sucht.

 

[Hauzuruck]

Alternativ bieten auch diverse IDEs entsprechende Deloy Funktionen die einen Abgleich mit dem Webspace durchführen.

Das hat geholfen! Ich nutze NetBeans. Beim erstellen eines Projekts kann unter "3. Run Configuration" die Option "Run As: Remote Web Site" gewählt werden. Diese Option ermöglicht genau das.

Danke für den Hinweis.

 

[Yuuri]

Von Git auf dem Webspace rate ich dringendst ab. Ist zwar super bequem kann aber ein Sicherheitsproblem werden wenn man ".git" nicht absichert oder es bei einem Anbieterwechsel vergisst die Absicherung zu überprüfen.

Das ist aber nicht das Problem von git, sondern der schon immer absolut fragwürdigen Methode das Web-Root im Projektverzeichnis liegen zu haben. Man sollte schon immer nen www, web, public o.ä. Unterordner haben, wo auch ausschließlich öffentliches Zeug liegt. Eigentlich... Kein src, kein assets, kein tests, kein composer.json, kein package.json und sonstiger projektbezogener, entwicklungstechnisch oder fürs Backend relevanter Kram, sondern rein die index.php. Wer selbst dafür zu blöd ist, einfach nen Unterordner zu erstellen und die Daten ne Ebene tiefer zu legen, der hat es mit git nicht anders verdient. Dass es auch große Systeme falsch machen... Naja, hauptsache Oma Brunhilde kann sich ihr eigenes Wordpress aufsetzen, welches binnen der nächsten Tage übernommen werden kann. -.-"

• Projekt/
  • .git/
  • assets/
  • bin/
  • config/
  • node_modules/
  • public/ <-- nur hier kommt alles Öffentliche rein
    • dist/
    • images/
    • index.php
  • src/
  • tests/
  • vendor/
  • .env
  • composer.json
  • composer.lock
  • docker-compose.yml
  • package.json
  • package-lock.json
  • webpack.config.js
  • pi pa po

Es gab auch schon genügend Sicherheitslücken, weil man im Production Environment die Tests von den Libs (namentlich phpunit) mit deployed und hier eben wieder das vendor-Verzeichnis von composer mit öffentlich liegen hat. https://thephp.cc/news/2020/02/phpunit-a-security-risk Aber das ist weder ein Problem von composer noch von phpunit, ja nicht mal dass die Tests mit deployed werden, sondern rein von der fragwürdigen Deployment-Methode -> Web = Projekt-Verzeichnis.

git ist nirgendwo Sicherheitsproblem, die Deployment-Methode ist es.

Besser wäre nur ein dedizierter Container. Auch ordentlich abgesichert, nicht als root agierend, Docker mit User Namespaces konfigurieren, nicht blind Volumes oder Sockets einbinden, Anwendung in ein eigenes Subnetz, keine Ports blind weiterleiten und und und... Dafür können die Container nämlich auch nix, wenn der User sich zu blöd anstellt und den Container als root laufen lässt und zudem noch den Docker Socket mit Schreibrechten einbindet oder gar das Netzwerk an den Host bindet.