staging.inyokaproject.org

Hallo,

ein schönes, weiteres Beispiel, warum "getestet: general" bei vielen Artikeln kontraproduktiv ist, weil sich kaum jemand über den Artikel Gedanken macht.

Danke für den Hinweis. Der Artikel kommt dann ins Archiv, weil PHP5 ja nun mal EOL ist.

Gruß, noisefloor

Hallo,

archiviert.

Falls jemand den Artikel dearchiviert haben möchte, um das ganze auf PHP 7 umzuschreiben → bitte hier kurz posten.

Gruß, noisefloor

Ich würde mich freiwillig melden zwecks Aktualisierung des Artikels. ☺

Gruß, M.

(bekennender ZF-Fan)

Hi!

@ mubuntuHH Habe dir den Artikel in die Baustelle/Zend-Framework geschoben - bitte noch das Fertigstellungs-Datum anpassen, und für welche Ubuntuversion es getestet wird, auch noch angeben. Viel Erfolg!

so long
hank

@Heinrich_Schwietering: Danke, habe ich entsprechend geändert.

Hi Also, ich habe den Artikel nun überarbeitet und aktualisiert. Wer mag bitte noch mal drüber gucken?

Vielen Dank für die umfangreiche Überarbeitung!

Ich bin nicht ganz durch gekommen (ist ja ne Menge Holz) - der Artikel liest sich IMHO schlüssig. Da ich kein Entwickler bin, kann ich zum Kern-Inhalt nicht viel sagen, das müssten andere machen.

Zwei Punkte:

• Der Artikel ist ja aktuell "nur" für 18.04 getestet. Damit sollten alle Hinweise im Artikel auf 18.04 (oder einmal auch "In älteren Ubuntu-Versionen") entfernt werden, das ist an diesen Stellen nicht mehr relevant.

• PHP 5.6 sollte im Artikel nicht mehr auftauchen, das ist EOL

Gruß BillMaier

BillMaier Danke für Dein Feedback!

Da Du sagst, dass Du kein Entwickler bist, hoffe ich, dass sich auch jemand themennahes dazu äußert. 😐

Ich sammele erst ein mal und werde dann alles umsetzen!

Gruß M.

Hallo mubuntuHH,

ich habe die Gelegenheit genutzt, den Artikel durchzuarbeiten und ein paar Punkte für deine Sammlung zusammengetragen. ☺ Getestet habe ich sowohl mit 16.04 als auch 18.04.

Mit Blick auf die entweder veralteten Versionen in den Repositories (zend-framework) oder die vom Funktionsumfang her ggf. nicht ausreichenden Pakete (php-zend-*) könnte ich mir vorstellen, dass hier ein entsprechender Hinweis erfolgt und dann wirklich nur detailliert auf die Installation via composer eingegangen wird. Das würde meiner Meinung nach wesentlich mehr Struktur in das Installationskapitel bringen.

Um beim Thema Installation zu bleiben: Für die Installation des kompletten Zend Framework mittels

composer require zendframework/zendframework 

muss ich mindestens die Pakete composer, php-mbstring und php-xml installieren. Für das derzeit verwendete Beispiel

composer require zendframework/zend-captcha 

reicht dagen die Installation des Pakets composer aus.

Im nächsten Schritt habe ich das Codebeispiel auf der Kommandozeile ausprobiert (Kopieren & Einfügen nach Test.php ⇒ php Test.php). Neben der Installation von zend-captcha war noch die Installation von zend-validator, zend-text und zend-session mittels

composer require zendframework/zend-validator zendframework/zend-text zendframework/zend-session 

notwendig. Ich habe mangels Ausgabeanweisungen keine Ausgabe erwartet, allerdings auch keine Fehlermeldungen wegen fehlender Bibliotheken. Hier vielleicht ein anderes Hallo Welt-Beispiel entwerfen und testen oder alternativ auf die später folgende Beispielanwendung verweisen.

Im Kapitel zur MVC-Anwendung habe ich die ersten Unterschiede zwischen 16.04 und 18.04 bemerkt, wobei diese gerade für den Produktivbetrieb irrelevant sein sollten. Unter 16.04 funktioniert die Kommandozeile

php -S 0.0.0.0:8080 -t public public/index.php 

nicht, sodass eine weiße Seite im Browser ausgegeben wird. Entferne ich den Teil public/index.php, sehe ich die erwartete Startseite. Der Befehl

composer serve 

ist hiervon genauso betroffen, da die composer.json ein Skript serve wie die eben gelesene php-Anweisung definiert. Unter 18.04 funktionieren beide Befehle hingegen makellos.

Das Unterkapitel zur Apache-Konfiguration kommt mir etwas unaufgeräumt vor. Hier bietet sich doch an, die einzelnen Punkte entweder durch eine Aufzählung oder durch Absätze nochmals voneinander zu trennen.

Das war's nun aber erstmal. Ich habe noch zwei kleine Tippfehler korrigiert (Semikolon am Ende der use-Zeile im Codebeispiel; Bestätigst man), falls du also eine lokale Version bearbeitest, hast du nun die Info. ☺

Ein paar doofe Fragen:

aus dem Entwurf:

Bei der Installation per Composer (oder auch Git) hat man zwar den Vorteil, die neuste Version zu erhalten, muss sich dann aber um die Updates - auch die sicherheitsrelevanten - selbst kümmern.

php-zend-code z.B. ist in den Paketquellen in universe, wo einem gar keine Sicherheitsupdates garantiert werden. Ich find der Absatz suggeriert zumindest, dass man über die Paketquellen Sicherheitsupdates bekommen würde – dem ist aber auch nicht so…

Aus Sicherheitsgründen niemals den PHP Server für Produktiv-Server oder für Rechner, die über den Port, den der PHP-Server nutzt, aus dem Internet erreichbar sind, nutzen.

Warum steht dann darüber 0.0.0.0:8080 statt 127.0.0.1:8080? Das könnt einem naiven c&p-er doch schon mal was bringen. 😉

Da es ein Beispiel mit Zend-Db gibt, wie schützt einem das vor SQL-Injection? (gut, ist keine Usereingabe da, aber da wird man früher oder später drauf stoßen IMO.) Zumindest ein Doku-Link wäre nett.

Will man wirklich noch, dass PHP-Code in /var/www/html/ liegt?

Viele Grüße
Chris

@Cranvil @chris34 Vielen Dank für Euer hilfreiches Feedback und insbesondere fürs Testen, Cranvil

Cranvil schrieb:

Mit Blick auf die entweder veralteten Versionen in den Repositories (zend-framework) oder die vom Funktionsumfang her ggf. nicht ausreichenden Pakete (php-zend-*) könnte ich mir vorstellen, dass hier ein entsprechender Hinweis erfolgt und dann wirklich nur detailliert auf die Installation via composer eingegangen wird. Das würde meiner Meinung nach wesentlich mehr Struktur in das Installationskapitel bringen.

chris34 schrieb:

Bei der Installation per Composer (oder auch Git) hat man zwar den Vorteil, die neuste Version zu erhalten, muss sich dann aber um die Updates - auch die sicherheitsrelevanten - selbst kümmern.

php-zend-code z.B. ist in den Paketquellen in universe, wo einem gar keine Sicherheitsupdates garantiert werden. Ich find der Absatz suggeriert zumindest, dass man über die Paketquellen Sicherheitsupdates bekommen würde – dem ist aber auch nicht so…

Das ist ein guter Punkt. Und ehrlich gesagt erschließt sich es mir nicht ganz, warum ausgerechnet nur diese Pakte in den Quellen sind. Und php-zend-db ist ab 19.04 gar nicht mehr in den Quellen, php-zend-code aber schon (??) Vielleicht könnt Ihr mir kurz auf dies Sprünge helfen, ganz allgemein: Wer entscheidet wie, was in den Ubuntu-Quellen rein kommt? Kann es sein, dass die derzeitigen php-zend-* Pakte nur deshalb 'drinn sind, weil andere Pakete vielleicht von ihnen abhängig sind? Wenn ja, wie kann ich das herausfinden? Ich beabsichtige den Bereich über die Installation aus den Paketquellen komplett zusammen zu streichen. Ein kurzer Hinweis "Zwar sind in den Paketquellen einzelne Zend-Pakete vorhanden, man sollte diese aber besser nicht benutzen...blabla..besser mit Composer..usw." sollte dann auch genügen. Was meint Ihr?

chris34 schrieb:

Warum steht dann darüber 0.0.0.0:8080 statt 127.0.0.1:8080? Das könnt einem naiven c&p-er doch schon mal was bringen. 😉

Nun ja, 0.0.0.0 ist dann sinnvoll, wenn, der Server, auf dem das Projekt läuft, nicht der Rechner ist, auf dem das ZF-Projekt angeguckt werden soll. Die offizielle ZF-Doku empfiehlt auch, 0.0.0.0:8080 zu nehmen. Der Artikel ist ja jetzt auch keine detaillierte Abhandlung über den PHP-Server. Auch deshalb habe ich die Totschlag-Warnung, das bloß nicht produktiv so zu machen, rein gehauen. 😉

chris34 schrieb:

Da es ein Beispiel mit Zend-Db gibt, wie schützt einem das vor SQL-Injection? (gut, ist keine Usereingabe da, aber da wird man früher oder später drauf stoßen IMO.) Zumindest ein Doku-Link wäre nett.

Auch hier, das ist jetzt keine Abhandlung über einzelne ZF-Komponenten; zend-deb war nur als Bsp. Auf SQL-Injection einzugehen, würde wirklich den Rahmen sprengen - dann streiche ich lieber das Bsp. auf ein absolutes Mindestmaß zusammen.

chris34 schrieb:

Will man wirklich noch, dass PHP-Code in /var/www/html/ liegt?

Auch ein sehr, sehr guter und wichtiger Punkt! Tatsächlich ist ZF so konzeptioniert, dass es ein public-Verzeichnis gibt, in dem NUR die index.php liegt. Die ganze n Klassen und Module liegen aber eine Ebene höher und sollte nicht über das Internet erreichbar sein. Werde ich noch einbauen!

@Cranvil Deine Ergebisse Deines Testes (Abhängigkeiten und das Problem mit composer serve werde ich auch berücksichtigen.

LG M.

mubuntuHH schrieb:

Wer entscheidet wie, was in den Ubuntu-Quellen rein kommt? Kann es sein, dass die derzeitigen php-zend-* Pakte nur deshalb 'drinn sind, weil andere Pakete vielleicht von ihnen abhängig sind? Wenn ja, wie kann ich das herausfinden?

Kann mehrere Gründe haben – von „es gibt da wirklich Abhängigkeiten“ bis hin zu „war gerade nicht bei Debian paketiert“. Ggf. hilft Paketquellen (Abschnitt „Die-Komponenten-bei-Ubuntu“) noch ein wenig weiter.

Ich beabsichtige den Bereich über die Installation aus den Paketquellen komplett zusammen zu streichen. Ein kurzer Hinweis "Zwar sind in den Paketquellen einzelne Zend-Pakete vorhanden, man sollte diese aber besser nicht benutzen...blabla..besser mit Composer..usw." sollte dann auch genügen. Was meint Ihr?

IMO so machen. Bei einem Webdienst finde ich keine Sicherheitsupdates (wegen Pakete in universe) fahrlässig.

Nun ja, 0.0.0.0 ist dann sinnvoll, wenn, der Server, auf dem das Projekt läuft, nicht der Rechner ist, auf dem das ZF-Projekt angeguckt werden soll. Die offizielle ZF-Doku empfiehlt auch, 0.0.0.0:8080 zu nehmen. Der Artikel ist ja jetzt auch keine detaillierte Abhandlung über den PHP-Server. Auch deshalb habe ich die Totschlag-Warnung, das bloß nicht produktiv so zu machen, rein gehauen. 😉

Nenn mich langweilig, aber als (sicherheitstechnisch guten) Standard würde ich erstmal 127.0.0.1:8080 im Wikiartikel nennen. Da kann man das selbst naiv auf nem produktiv System starten und es ist nicht von außen erreichbar (außer man macht komische Dinge mit iptables o.ä.). Wenn wirklich gewollt, kann man statt auf 127.0.0.1 auf der LAN-IP, der public IP oder eben auch auf allen lauschen. Beim aktuellen kann man sich halt IMO direkt ungewollt ins Knie schießen, weil es ggf. direkt öffentlich erreichbar ist.

Viele Grüße
Chris

chris34 schrieb:

als (sicherheitstechnisch guten) Standard würde ich erstmal 127.0.0.1:8080 im Wikiartikel nennen.

+1

Wer es anders braucht sollte wissen was er braucht und was er da tut.

Gruß BillMaier

jfi:

Artikel ist seit 21. 07. 19 online. Er wurde von der Baustelle verschoben, der Archivartikel gelöscht. Enjoy. 👍

Hallo mubuntuHH,

bitte niemals innerhalb eines Artikels hart auf sich selbst verlinken. (Hier konkret in diff/972222/972483, Zeile 201.) Das führt nur zu Problemen, wenn der Artikel umbenannt wird (Baustelle, Archiv o. ä.).

Wenn du innerhalb eines Artikels auf einen Abschnitt in diesem Artikelverweisen möchtest, bitte immer

[#bar bar]

verwenden, und nicht:

[:foo/#bar:bar]

Das gilt auch für das Einbinden von Anhängen (also Bilder u. ä.).

Hinweis erfolgt öffentlich, da auch für anderen User relevant.