Forum: PC-Programmierung Probleme mit php in html


von Johannes (Gast)


Lesenswert?

Hallo,
ich wollte mir php angucken, habe aber beim hallo welt schon ein 
Problem.
Ich habe als Betriebssystem Ubuntu
1
<html>
2
 <head>
3
  <title>PHP-Test</title>
4
 </head>
5
 <body>
6
 <?php echo '<p>Hallo Welt</p>'; ?>
7
 </body>
8
</html>

Die Ausgabe siehg aber wie folgt aus
1
Hallo Welt
2
3
'; ?>
Hallo Welt ist auch nicht fett sondern normal und dann wird der rest 
also '; ?> auch noch dargestellt.

Was habe ich falsch?

Ich habe php 7.4.9

von Sascha W. (sascha-w)


Lesenswert?

Welcher Webserver?
Mit dem p-Tag erzeugst du einen Absatz, für Fett musst du den b-Tag 
nehmen.

Sascha

Beitrag #6467490 wurde vom Autor gelöscht.
von rbx (Gast)


Lesenswert?

vielleicht sind ein paar html Grundlagen auch nicht so verkehrt:
https://www.w3.org/MarkUp/Guide/

von Julius (Gast)


Lesenswert?

Hast Du einen Webserver oder rufst öffnest du die Datei einfach vom 
Filesystem?
also

file:///home/DU/test.html
oder http://localhost/test.html

von Jim M. (turboj)


Lesenswert?

Im Webbrowser die Quelltext Ansicht einschalten.

Wenn die php Tags sichtbar sind (und das ist vermutlich der Fall): PHP 
ist nicht korrekt eingeschaltet oder der Webserver erkennt die Datei 
nicht (Dateiendung).

von Julius (Gast)


Lesenswert?

Wenn wir dir schon helfen sollen, dann brauchen wir auch ein Feedback.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ist doch offensichtlich, daß der PHP-Code nicht ausgeführt wird weil man 
PHP nicht ohne Webserver in HTML einbetten kann... dafür braucht man 
kein Feedback.

von sid (Gast)


Lesenswert?

Ernsthafterweise muss ich sagen,
dass ich schon das mischen von html mit php
ungefähr so gut finde wie Schweissfüsse..

Diese Unsitte haben die Deppen von Wordpress 'Salonfähig' gemacht,
nichts umso weniger gehört das getrennt!

Gut.. für etwas banales wie dieses Beispiel da.. kein Ding;
für productioncode... NOPE NEVER!!
Also gewöhn es Dir besser garnicht erst an.

benutze stattdessen templates die dann mit den
Daten aus der php gefüllt werden,
rudimentäre template-systeme lassen sich schnell selber malen,
Du kannst aber auch einfach ein fertiges Templatesystem benutzen
(smarty zB )
sind wenige includes und der php code bleibt sauber,
und man muss html nur an EINER stelle ändern nicht an hunderten!

'sid

von STK500-Besitzer (Gast)


Lesenswert?

Johannes schrieb:
> Was habe ich falsch?

Du hast deine Datei scheinbar nicht ".php" benannt oder php ist auf 
deinem Webserver nicht eingeschaltet.

von sid (Gast)


Lesenswert?

Sorry.. rage no response .. uups

Also das Problem ist Deine Dateiendung.. mach .php draus und es wird 
vermutlich klappen wie Du willst

eine html wird vom php prozessor gewöhnlicherweise ignoriert falls Du 
dem Server nicht anderes befiehlst.

(Im Grunde was Jim schon anmerkte)

'sid

PS und stimmt.. hast Du keinen webserver mit php prozessor kannstes 
direkt vergessen (windows localhost mit xampp allerdings reicht schon 
dicke damit es klappt)  ;)

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> dass ich schon das mischen von html mit php
> ungefähr so gut finde wie Schweissfüsse..
Ich mags auch nicht, schreibe meine PHP-Seiten komplett in PHP, dadurch 
kommt zwar etwas Overhead durch die echo-Zeilen zusammen und es kostet 
vielleicht ein wenig Performance, aber es sieht für mich einfach besser 
aus.

> Diese Unsitte haben die Deppen von Wordpress 'Salonfähig' gemacht,
> nichts umso weniger gehört das getrennt!
Nee, das gab's vorher schon weit verbreitet, einfach weils dadurch so 
einfach ist, PHP in bereits bestehende HTML-Seiten einzubinden. 
Vielleicht hat's über die Jahre mal nachgelassen, aber ganz zu Anfang 
hat man das überall so gesehen weil niemand die alten HTML-Seiten 
komplett neu basteln wollte.

Edit:
Hast Du den Thread wegen meinem Weltraum-OBG schon wieder vergessen? ;)

: Bearbeitet durch User
von sid (Gast)


Lesenswert?

Ben B. schrieb:
>> dass ich schon das mischen von html mit php
>> ungefähr so gut finde wie Schweissfüsse..
> Ich mags auch nicht, schreibe meine PHP-Seiten komplett in PHP, dadurch
> kommt zwar etwas Overhead durch die echo-Zeilen zusammen und es kostet
> vielleicht ein wenig Performance, aber es sieht für mich einfach besser
> aus.
>
>> Diese Unsitte haben die Deppen von Wordpress 'Salonfähig' gemacht,
>> nichts umso weniger gehört das getrennt!
> Nee, das gab's vorher schon weit verbreitet, einfach weils dadurch so
> einfach ist, PHP in bereits bestehende HTML-Seiten einzubinden.
> Vielleicht hat's über die Jahre mal nachgelassen, aber ganz zu Anfang
> hat man das überall so gesehen weil niemand die alten HTML-Seiten
> komplett neu basteln wollte.
>
> Edit:
> Hast Du den Thread wegen meinem Weltraum-OBG schon wieder vergessen? ;)

Ja gegeben hat es das schon vorher, aber jeder WEbdesigner der sich auch 
so nennen darf hat versucht es zu unterlassen,
Heimwerker haben natürlich weitergemacht...
Seit der WP Schitte aber scheinen auch professionelle Dienstleister dazu 
übergegangen zu sein, wieder zu mischen (das heisst viele sind dazu 
übergegangen nurnoch WP Mist zu ver'kaufen')
Egal..

Ja wenn man sich mit einzel echos behilft, wird es schnell 
unübersichtlich,
deswegen sag ich ja .. n einfaches templatesystem ist schnell gebastelt
im template einfach phpvariablen nutzen ($variable),
mit eval ersetzen lassen und dann ein echo
1
//fetch template und output
2
$template = addslashes(implode('', file("template/std.tpl")));
3
eval ("\$output = \"$template\";");
4
echo stripslashes($output);

Man muss eben nur sicherstellen, dass man weiss was man da ins eval 
schickt;
aber das ist ein anderes Thema;)

smarty ist mMn für die meisten Dinge aber sinnvoller als ein 
selbstgestricktes templatesystem, allerdings auch n bisschen grösser als 
ein dreizeiler ;)

'sid

PS: Nein 'vergessen' nicht, aber dank Corona 'Nebenwirkungen' und 
daranhängenden Rattenschwänzen ist mein Zeitmanagement mehr als nur ein 
bisschen durcheinander; Du bist also leider weiter nach unten auf meinem 
Schreibtischstapel gewandert... tut mir leid.

von ThomasW (Gast)


Lesenswert?

hab das Gefühl hier wird vergessen, dass PHP schon immer selbst eine 
Template-Engine war. Für die meisten Webdesigner macht es keinen 
Unterschied ob man <?php echo $title; ?> oder doch %%title%% schreibt.

Aber für ersteres brauchst Du keinen Haufen an PHP Code nur um das 
nachzubauen, was die Engine selbst kann. Spätestens bei 
if/then/else/forEach sind die Systeme, die ich kenne, nicht einfacher 
als gleich PHP zu verwenden. Und ein MVC-Ansatz ist auch da wunderbar 
möglich!

von sid (Gast)


Lesenswert?

Ah da haben wir ihn ja.. den Wordpress verfechter...
kotz (Wordpress.. nicht Thomas!)

ThomasW schrieb:
> hab das Gefühl hier wird vergessen, dass PHP schon immer selbst eine
> Template-Engine war.

Nein Du missverstehst, php ist selbst keine template-engine,
php ist eine skriptsprache spezifisch erdacht um Webseiten zu erstellen,
und ermöglicht dem Nutzer damit alles zu bauen was man erdenken kann,
zu dem "alles" gehört eine template engine klar;
macht php aber nicht zu einer template engine;

So wie die Kiste Lego eben kein Barbie Traumhaus ist aber eins sein 
könnte ;)

Ich gebe Dir aber recht, dass manche template-engines nicht einfacher zu 
benutzen sind als direkt in php die Konditionierungen vorzunehmen.
das ist ja auch nicht deren Zweck.

Es macht nämlich durchaus Sinn diese Funktionen in einer vollständigen 
template-engine zu haben,
eben um die Anzahl der templates gering zu halten
und die Wartbarkeit des resultierenden Codes zu erleichtern.

(semi-fiktives Beispiel)
So zB macht es Sinn dass dieses Forum nur ein template zur 
Themen-Darstellung nutzt,
die php entscheidet ob ein user GAST NUTZER oder MODERATOR ist
und die template-engine danach entscheidet wo und ob ein Bearbeiten 
knopf an den Beiträgen auftaucht.
ohne dass man mehrere templates braucht für Gäste/Nutzer und Moderatoren
und ohne dass man den html-code für besagten Knopf in der php 
mitschleppen muss (und ggf ändern falls man das design updaten möchte)

anderes Beispiel:
template engines sind gewöhnlich auch Mehrsprachig ausgelegt,
sodass Wiederkehrende Inhalte (Linkbezeichnungen, Buttontext, 
Formular-erklärungen etc.pp.)
nicht in den phps gesucht werden müssen,
sondern man sie nur in der Sprachdatei zu ändern hat ggf,
und man bequem auch neue Sprachen hinzufügen kann durch eine simple neue 
Sprachdatei.
Um fallbacks und so kümmert sich dann die template engine alleine
und man hat wiedr einen gaaaanzen Haufen (eigenen) php code gespart.

Mehr Beispiele für die man sich keine php Zeilen anzulegen braucht die 
aber nützlich sind in der templateengine zu haben:
uhrrzeit/Datum, odd/even-Farbgestaltung für Listen [themenübersicht], 
entfernen leerer html container [das kann der WP scheiss zB garnicht]
usw usf...

'sid

PS ich glaube wir kommen vom Thema ab.. mein Fehler.. tut mir leid!

von ThomasW (Gast)


Lesenswert?

sid schrieb:
> Es macht nämlich durchaus Sinn diese Funktionen in einer vollständigen
> template-engine zu haben,
> eben um die Anzahl der templates gering zu halten
> und die Wartbarkeit des resultierenden Codes zu erleichtern.

bin einfach kein Freund davon in einer Skriptsprache Dinge nachzubauen, 
die schon fix und fertig als natives Servermodul bereit stehen.

schau Dir mal das Zend-Framework an. Dort wird ganz gut gezeigt wie man 
das mit reinem PHP löst. Inklusive Rollen, Mehrsprachigkeit und allem 
was man sich vorstellen kann. Das alles mit Views die einfache HTML 
Fragmente mit Inline-PHP sind. Ohne eval! Okay, ZF ist furchtbar 
Akademisch und deshalb ne Schnecke, aber es ist gut lesbar und ne gute 
Vorlage um sich ein performantes MVC zu bauen.

Vielleicht liegt meine Sichtweise auch n bisschen daran, dass in unseren 
Projekten heute kaum noch großartig fertige Seiten vom Server 
ausgeliefert werden. Da ist PHP ein schnelles Backend für REST-Calls und 
die Views werden in Angular, React, Swift oder Kotlin geschrieben.

sid schrieb:
> PS ich glaube wir kommen vom Thema ab.. mein Fehler.. tut mir leid!

ach was, wir nehmen doch nur die nächsten Fragen des TE vorweg ;-)

von sid (Gast)


Lesenswert?

ThomasW schrieb:
> bin einfach kein Freund davon in einer Skriptsprache Dinge nachzubauen,
> die schon fix und fertig als natives Servermodul bereit stehen.

Du missverstehst ...
PHP ist die skriptsprache,
PHP ist auch nichts ALS eine skriptsprache
es gibt in php keine dedizierten template evaluierungs funktionen,
die muss man sich selber stricken.
(oder fertig gestricktes aus dritter Hand nutzen)

ThomasW schrieb:
> schau Dir mal das Zend-Framework an. Dort wird ganz gut gezeigt wie man
> das mit reinem PHP löst. Inklusive Rollen, Mehrsprachigkeit und allem
> was man sich vorstellen kann.

Schau Dir mal smarty an, das ist reines php
und macht exakt das ohne zusätzlichem Framwork ;)

(Zend ist super.. manchmal, und manchmal ist es nur Klotz am Bein)

REACT und SWIFT teilen mir übrigens klar mit, dass Du mit klassischer 
HTML erzeugung zur Darstellung von Internetseiten eher nicht täglich zu 
tun hast.
was ich von KOTlin halte sage ich mal nicht, es steckt aber im Namen
Im Grunde ist es wieder das beliebte Spiel derer die meinen das Internet 
sei für Mobiltelefone erfunden worden.

Das erklärt aber auch das MVC gefasel ('tschuldige) denn das ist im 
Grunde genauso stumpfsinnig wie permanentes OOP Geseiere.
Ja, wo es Sinn macht ... aber es ist weder das Allheilmittel noch
immer der beste Ansatz (ganz zu schweigen davon der einzige zu sein)!

Klassische HTML braucht kein ModelViewControlling, sowie eine 
Taschenrechner-App keine objektorientierung braucht.

Ich red mich hier gleich in Rage darüber, warum man soviele Frameworks 
wie nur irgendwie möglich vermeiden sollte.
(und da zählt Angular zu den ersten die abzuschaffen sich positiv auf 
die Gesamtheit auswirken würde)

Egal, ich lass das lieber..
ich merke, dass ich dabei (hier im Forum generell) gegen das Blöcken von 
Schafen anzureden versuche,
Auto-update Lemminge die meinen Cookie-richtlinien seien besser als ein 
Browser der Cookies generell blockieren kann.

Hat ja keinen Zweck Don Quixote spielen zu wollen.

Zurück zum Thema:

ThomasW schrieb:
> bin einfach kein Freund davon in einer Skriptsprache Dinge nachzubauen,
> die schon fix und fertig als natives Servermodul bereit stehen.

Du bist also kein Fan davon drittsoftware zu (schreiben oder) nutzen 
weil Du lieber drittsoftware nutzt die Deiner Aussage nach langsamer 
ist..
okay.. aber Du verzeihst, dass das inhaltlich nicht wirklich Sinn macht, 
oder?

In diesem Sinne

shalömmchen

'sid

von Andre (Gast)


Lesenswert?

sid schrieb:
> okay.. aber Du verzeihst, dass das inhaltlich nicht wirklich Sinn macht,
> oder?

Dein Beitrag? Stimmt, der ist wirklich sinnlos.

Warum du so ein Fan von Template Engines bist erklärst du auch nicht. 
Ich sehe da keine Vorteile...

Variante 1: template.smarty
> <h1>%%headline%%</h1>

Variante 2: template.php
> <h1><?php echo $headline; ?></h1>

Inhaltlich machen die beiden Varianten das Gleiche. Aber für Variante 1 
musst du in PHP einen Parser schreiben, der die .smarty Datei ausführt 
und die Variable "headline" ausgibt.
Das kannst du auch direkt mit Variante 2 erledigen, der PHP Parser läuft 
sowieso schon.

Das verletzt meiner Meinung nach auch keine MVC Design Regeln.
Du kannst die Anwendung bzw. Logik weiterhin in reinen PHP Dateien 
anlegen, was ich auch empfehle.
Ob die Anwendung dann am Ende ein template.php einbindet oder einen 
Parser für template.smarty anwirft ist doch davon völlig unabhängig. 
Aber letztere Variante deutlich umständlicher.

P.S. in meinen wilden PHP Tagen (noch bevor das mit Objekten was 
anfangen konnte...) habe ich auch unendlich viele Stunden damit 
verbracht, mir eigene Engines zu schreiben oder mich in Smarty 
einzuarbeiten.
Lohnt sich meiner Meinung nach alles nicht. Viel wichtiger ist ein 
stabiles Framework, das eine Datenbank Abstraktion, Sessions, Aufruf der 
Templates usw. schön kapselt. Dieses Grundgerüst muss man ja nicht jedes 
mal selbst neu erfinden.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

als reines PHP: echo"<h1>$headline</h1>";

von sid (Gast)


Lesenswert?

Andre schrieb:
> Variante 1: template.smarty
>> <h1>%%headline%%</h1>
>
> Variante 2: template.php
>> <h1><?php echo $headline; ?></h1>
>
> Inhaltlich machen die beiden Varianten das Gleiche. Aber für Variante 1
> musst du in PHP einen Parser schreiben, der die .smarty Datei ausführt
> und die Variable "headline" ausgibt.
> Das kannst du auch direkt mit Variante 2 erledigen, der PHP Parser läuft
> sowieso schon.

bei zwei drei variablen macht das in der tat ausser in der Anzahl der 
spitzen klammern keinen Unterschied, korrekt.

hast Du aber 50-60 variablen zu parsen und ggf sogar noch vier fünf 
Arrays dabei, wird das ganz schnell ein ganz fürchterliches 
Durcheinander

hier mal ein winziger Ausschnitt meines CMS
(der Ausschnitt erstellt nur das side-panel Menü)
1
{foreach key=n item=p from=$parent}
2
  {if !empty($groups.$n)}
3
    {if $groups.$n|@count gt 1}
4
        <li {if $active.m == $n}class="active"{/if}>
5
          <a h-ref="javascript:;">
6
          <i class="fa fa-{$p.ico}"></i> 
7
          <span class="title">{$p.name}</span>
8
          <span class="arrow"></span>
9
          </@>
10
          <ul class="sub-menu">
11
      {foreach item=m from=$groups.$n}
12
            <li {if $active.p == $m.page}class="active"{/if}>
13
              <a h-ref="{$m.page}?h={$m.hof}">
14
              <i class="fa fa-{$m.ico}"></i>
15
              {$m.text}</@>
16
            </li>
17
      {/foreach}
18
          </ul>
19
        </li>
20
    {else}
21
      {foreach item=m from=$groups.$n}
22
        <li {if $active.m == $n}class="active"{/if}>
23
          <a class="" h-ref="{$m.page}?h={$m.hof}">
24
          <i class="fa fa-{$m.ico}"></i>
25
          <span class="title">{$p.name}</span>
26
          </@>
27
        </li>
28
      {/foreach}
29
    {/if}
30
  {/if}
31
{/foreach}
All das ist leicht auch in php ohne smarty zu machen, sicherlich;
aber weswegen sollte ich den ganzen html krempel in der php haben 
wollen?
wenn der Code nachher wartbar sein muss, ist LESBARKEIT ein hohes gut.
das Trennen von html und php script ist dabei unfassbar nützlich.
(auch kann ich so deutlich schneller das html layout ändern, ohne die 
php auch nur anzufassen)
UNd ja die geschweiften Klammern der smarty tpl engine isnd mir auch 
manchmal ein Dorn im Auge..
aber einen Tod muss man sterben.

sicherlich ist das aber um KLASSEN besser als vor jede Variable und 
jedes Array-item ein echo zu malen...
ich mein, mach doch mal und schau wieviel byte länger dein Resultat 
dadurch wird.
und mein 'längstes' solches template hat fast 64kb und greift zur 
Metrik-erfassung auf 42 teils mehrdimensionale arrays zurück mit 
insgesamt in etwa 5500-6000 individuellen datenpunkten
[Du weisst schon, visits, pagetime, browserdaten, referrer, sales, POS, 
location etc...]
da werden Farben, icons und grössen einzelner divs angepasst je nach 
content,
alternierende Farben in tabellen angelegt mit zusatzfuntionen versehen 
wo nötig
(Rechnungen einsehen, Zahlung verfolgen, Kunden kontaktieren etc.pp.)

wenn ich die geschätzt 12kB smarty-funktionen (if then else foreach 
gedöns)
abziehe (die tatsächlich 1:1 die php funktionen spiegeln)
muss ich immernoch mindestens 50kB html in meine php schmeissen,
PLUS dem header template (12kB) plus dem Menü template (7kB) plus dem 
Footer (4kB) und schwuppdiwupp kann ich weder mein template so schnell 
ändern wie im Moment (1 dropdown im footer um das andere templateset zu 
wählen) noch kann ich so einfach wie jetzt meine php pflegen, da sie 
zugemüllt wurde von etwa 80kB html
und hat damit defacto die Dateiendung fast nichtmehr verdient,
da sie zehnmal mehr html als php code hält.

Ich bin nicht der grösste Fan von smarty um ehrlich zu sein, mir ist nur 
nichts untergekommen bisher was sich so gefällig an meine Bedürfnisse 
angepasst hat. Wie immer passt mir das ein oder andere nicht, aber es 
ist noch das Beste System was ich je ausprobiert hab
Es ist unfassbar robust, schnell und dank caching auch 
ressourcenschonend
(macht ja keinen Sinn die identische html jedesmal neu erstellen zu 
lassen wenn man sie auch aus dem serverseitigen-smarty cache laden kann 
solange sich nichts ändert.. ist sogar deutlich schneller ;))
Ich hatte vor mein eigenes Templatesystem zu vervollständigen extra 
dafür, stimmt.
Hab dann aber schnell festgestellt, dass ich mehr und mehr Funktionen 
von smarty übernehme und diese selber zu schreiben ist recht 
Zeitaufwändig, wenn man es sorgfältig machen möchte... und nachdem ich 
etwa die 30% Marke überschritten hatte dachte ich so bei mir: "statt es 
zu kopieren nutz doch direkt smarty, ist halt drittanbieter weichware, 
aber spart ne Menge Zeit"
Hat auch Zeitreserven frei gemacht stattdessen an der Funktion des CMS 
selbst zu arbeiten ;)

Und wie gesagt selbst für einfaches Zeug bin ich der Meinung,dass html 
NICHT in php gehört und umgekehrt

da kommt dann wieder mein dreizeiler ins Spiel:
1
$template = addslashes(implode('', file("template/std.tpl")));
2
eval ("\$output = \"$template\";");
3
echo stripslashes($output);
std.tpl wär in Deinem beispiel so banal wie:
<h1>$headline</h1>
[eben direktes parsen von php variablen, liesst sich mit syntaxhighlight 
exakt wie stinknormaler html code]
ist nicht bulletproof, aber -mindestens mir- noch ums tausendfache 
lieber
als sich mit
solcher Kacke befassen zu müssen wie:
<h1><?php echo $headline; ?></h1>
[das geht GARNICHT, da muss dePabba von brechen!!]

und wie gesagt, bei zwei Variablen wär's mir trotzdem fast noch egal,
aber sobald da ernsthafter Content dynamisch erzeugt wird, ist das 
einach absolut inakzeptabel
(wordpress Abfall quasi)

'sid

PS achwas.. href und /a wird als spam markiert selbst in code tags... 
deswegen hab ich's mal modifiziert

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Naja das sind wieder Stilkriege genau wie bei Programmiersprachen 
allgemein, C-Frameworks und neuerdings auch Datenbanken. Oder die 
allseits beliebte Frage, welcher Mikrocontroller denn der beste sei.

Ich habe z.B. überhaupt kein Problem damit, PHP und HTML zusammen zu 
lesen, zumal gute Editoren das sowieso highlighten. Ich finde das sogar 
praktisch, da ich mir die Sachen meistens nicht in verschiedenen Dateien 
zusammensuchen muß - außer irgend ein Nappel hat sich einen Spaß draus 
gemacht und gefühlt tausend Includes in 50 Ebenen zusammengebastelt. An 
die echo-Zeilen gewöhnt man sich und ich tippe das schneller als dauernd 
diese geschweiften Klammern. Da würde ich wohl schnell einen Krampf von 
bekommen.

von TotoMitHarry (Gast)


Lesenswert?

Ben B. schrieb:
> außer irgend ein Nappel hat sich einen Spaß draus
> gemacht und gefühlt tausend Includes in 50 Ebenen zusammengebastelt.

oder für einfache in PHP implementierte Funktionen eigene 
Klassenbasierte Funktionen mit über 500 verschachtelten Funktionen ala 
Wiederverwendbarkeit zu erstellen das man sich bei jedem Text im Browser 
fragen muss wo der schon wieder hergeholt wird :D

Sowas muss ich undokumentiert Warten weil der Freelancer verstorben ist 
und es nur der Webserver als Ansatz übrigblieb. Dazu noch zig 
verstrickte Klassen und Custom Vars die PHP auch so kann, kommt mir 
manchmal vor als wenn das von PHP1 Zeiten stammt und heute bis zu PHP7 
nicht verändert werden musste.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Naja, was am praktischen ist hängt ganz davon ab, was man vor hat.

Ein Vorteil vieler Templating libraries / frameworks, gegenüber direkt 
php, ist das Escaping. Mit reinem php muss ich ständig htmlentities() 
hinschreiben, bei templating frameworks/libraries muss man oft nur die 
richtige Klammer nehmen.

von sid (Gast)


Lesenswert?

TotoMitHarry schrieb:
> Sowas muss ich undokumentiert Warten weil der Freelancer verstorben ist
> und es nur der Webserver als Ansatz übrigblieb. Dazu noch zig
> verstrickte Klassen und Custom Vars die PHP auch so kann, kommt mir
> manchmal vor als wenn das von PHP1 Zeiten stammt und heute bis zu PHP7
> nicht verändert werden musste.

??? exakt diese Ausrede hab ich auch schon zu hören bekommen
"verstorben" muss wohl der Code sein für
"Ich hab's selber versucht, bin aber gescheitert"

Schlimmer als 'undokumentiert' ist übrigens schlecht FALSCH 
dokumentiert..
ich kann Dir sagen, in grauenhaftem Englisch falsch dokumentiert ist die 
Hölle.
Dann lieber ohne und nur mit ner groben doxygen übersicht arbeiten mMn.

'sid

von Julius (Gast)


Lesenswert?

Wir sind schon seeehr weit weg vom eigentlichen Thema.

von sid (Gast)


Lesenswert?

Julius schrieb:
> Wir sind schon seeehr weit weg vom eigentlichen Thema.

Da hast Du Recht...
genug von das!

Johannes? lüpptet nu?

'sid

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Johannes? lüpptet nu?
Der weiß inzwischen alles über Winnetou,
Kampfhubschrauber und beschissene Musik.

;)

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Ernsthafterweise muss ich sagen,
> dass ich schon das mischen von html mit php
> ungefähr so gut finde wie Schweissfüsse..
>
> Diese Unsitte haben die Deppen von Wordpress 'Salonfähig' gemacht,
> nichts umso weniger gehört das getrennt!

Entschuldige, aber diese Unsitte haben Apaches Server-Side Includes und 
danach PHP salonfähig gemacht, und verschiedene andere -- wie etwa 
embperl für Perl oder digiweb für Python -- haben es dann nachgemacht. 
Leider ist es allerdings unter PHP besonders weit verbreitet, übrigens 
auch schon in Anwendungen, die es lange vor Wordpress gab: OS-Commerce 
und PhpMyAdmin fallen mir da auf die Schnelle ein. Nichtsdestotrotz ist 
und bleibt es gruselig...

> benutze stattdessen templates die dann mit den
> Daten aus der php gefüllt werden,
> rudimentäre template-systeme lassen sich schnell selber malen,
> Du kannst aber auch einfach ein fertiges Templatesystem benutzen
> (smarty zB )

Wenn man es ganz genau nimmt, ist PHP ja selbst eine Templateengine... 
;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Johannes schrieb:
> Hallo,
> ich wollte mir php angucken, habe aber beim hallo welt schon ein
> Problem.
> Ich habe als Betriebssystem Ubuntu
>
1
> <html>
2
>  <head>
3
>   <title>PHP-Test</title>
4
>  </head>
5
>  <body>
6
>  <?php echo '<p>Hallo Welt</p>'; ?>
7
>  </body>
8
> </html>
9
>
>
> Die Ausgabe siehg aber wie folgt aus
>
1
> Hallo Welt
2
> 
3
> '; ?>
4
>
> Hallo Welt ist auch nicht fett sondern normal und dann wird der rest
> also '; ?> auch noch dargestellt.
>
> Was habe ich falsch?

Offensichtlich wird Dein Code nicht ausgeführt, sondern als HTML 
ausgeliefert. Der Webserver entscheidet (meistens anhand des 
Dateinamenerweiterung der angeforderten Ressource  wurde) ob und wie er 
die Datei vor der Auslieferung vorverarbeitet. In Deinem Fall müßte er 
die Datei durch den PHP-Interpreter jagen und dessen Ausgabe dann an den 
Client zurückliefern, aber genau das tut er offensichtlich nicht, und 
gibt stattdessen Deinen PHP-Code einfach als HTML-Datei zurück.

Nun ist es leider so, daß verschiedene Webserver unterschiedliche Modus 
haben, um PHP auszuführen. Einerseits gibt es die sehr selten genutzte 
Möglichkeit, PHP als CGI-Skript auszuführen -- das kennt kaum jemand, 
weil es ziemlich langsam ist, für jeden Request einen neuen Prozeß 
erzeugt und abräumg, und deswegen überhaupt keinen Spaß macht.

Dann gibt es verschiedene Möglichkeiten, die die meisten Webserver 
bieten, um PHP als Fast-CGI (FCGI) auszuführen. Dabei dient der 
Webserver im Wesentlichen als eine Art Reverse-Proxy. Das ist viel 
schneller, weil die PHP-Prozesse ständig laufen, und ist meist der 
bevorzugte Weg, weil PHP so unter einer eigenen Benutzerkennung laufen 
und so keine (mit korrekten Rechten versehenen) Date(i)en anderer 
Benutzer auf dem Systems lesen oder gar manipulieren kann.

Der Apache2-Webserver bietet mit mod_php noch eine Möglichkeit, den 
PHP-Interpreter in den Apache-Serverprozeß einzubinden. Das ist zwar die 
schnellste Möglichkeit, hat aber leider den Nachteil, daß die 
PHP-Skripte unter der Userkennung des Webservers laufen; diese 
Möglichkeit eignet sich also nicht für Shared Hosting-Umgebungen, bei 
denen mehrere Benutzer sich denselben Webserver teilen.

Obendrein soll es -- habe ich gehört -- noch Sonderkonfigurationen 
bestimmter Hoster geben, bei denen im Frontend ein Nginx als Reverse 
Proxy und im Backend ein Apache2 mit mod_php unter der Benutzerkennung 
des Kunden laufen soll.

Eine besonders elegante Möglichkeit, aber mit einer hohen zusätzlichen 
Lernhürde auch für erfahrene Benutzer verbunden, ist die Möglichkeit, 
PHP in einem Docker-Container hinter dem Nginx Reverse Proxy von Jason 
Wilder zu betreiben. Das mache ich sehr gerne, aber das erste Setup ist 
nichts für Anfänger und bringt auch einen erfahrenen UNIX- und 
Linux-Admin erstmal für ein, zwei Tage ins Schwitzen. Danach ist es 
allerdings extrem einfach und kann mit einem weiteren Container auch 
ohne weitere Aufwände automatisch perfekt mit Letsencrypt umgehen. [1]

Lange Rede, kurzer Sinn: zunächst solltest Du herausfinden, mit welchem 
Webserver Dein System betrieben wird, und danach, ob und wie PHP dort 
konfiguriert und ob es auch aktiviert ist. Dann solltest Du 
sicherstellen, daß Dein Skript die korrekte Dateinamenerweiterung hat 
und der PHP-Interpreter für diese Dateinamenerweiterung innerhalb jenes 
Verzeichnisses konfiguriert ist.

Um Dir sinnvoll helfen zu können, wäre es übrigens auch ganz schön, 
etwas mehr über das Umfeld zu erfahren: welches Betriebssystem (Linux 
oder Windows), welche Rechte hast Du darauf (root / Administrator oder 
normaler Benutzer), wie kannst Du auf das System zugreifen (nur per SFTP 
 FTPS  FTP / CIFS oder auch per Kommandozeile wie etwa mit ssh(3) 
oder, unter Windows, Putty bzw. MobaXTerm).

[1] https://hub.docker.com/r/jwilder/nginx-proxy

von Sheeva P. (sheevaplug)


Lesenswert?

Ben B. schrieb:
>> Diese Unsitte haben die Deppen von Wordpress 'Salonfähig' gemacht,
>> nichts umso weniger gehört das getrennt!
> Nee, das gab's vorher schon weit verbreitet, einfach weils dadurch so
> einfach ist, PHP in bereits bestehende HTML-Seiten einzubinden.

Absolut richtig! Ich wage sogar zu behaupten, daß das einer der 
wichtigsten Gründe für den Erfolg und die hohe Verbreitung von PHP war. 
Denn dadurch konnten auch Menschen, die nicht die geringste Ahnung von 
UNIX, Dateirechten, und irgendwelchen komplizierten 
Webserver-Konfigurationen, geschweige denn auch nur einen 
Kommandozeilenzugang für ihr Serversystem hatten (und ihn auch nicht 
hätten benutzen können), problemlos irgendwas Ausführbares auf ihren 
Server hochladen -- und es lief!

Ein anderer Grund für diese "Natur" von PHP war, daß Rasmus Lerdorf mit 
seinen "Personal Home Page Tools" und dem "Personal Home Page/Forms 
Interpreter" ja erst nicht mehr wollte als etwas wie Server-Side 
Includes auf Anabolika und Steroiden. Genau das -- diese Einbettung von 
Code in bestehende Seiten -- war aber auch für etliche Leute attraktiv, 
die bereits Homepages hatten, ein bisschen Dynamik hinzu fügen wollten 
(damals gerne etwa einen Counter oder ein Gästebuch).

Leider hat das PHP-Projekt seit damals nicht immer die besten 
Designentscheidungen getroffen, aber in letzter Zeit und vor allem mit 
Version 7 scheint sich das endlich wieder zu bessern. Trotzdem krankt 
die Sprache aus meiner Perspektive immer noch daran, sich ausgerechnet 
zwei der schlechtesten Beispiele aller Zeiten herausgesucht und 
nachprogrammiert zu haben: die Stringerarbeitung von C, keine 
Typsicherheit und dennoch die Objektorientierung von Java... aber naja, 
immerhin haben sie endlich sogar Namespaces implementiert, yay! ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Ben B. schrieb:
>>> dass ich schon das mischen von html mit php
>>> ungefähr so gut finde wie Schweissfüsse..
>> Ich mags auch nicht, schreibe meine PHP-Seiten komplett in PHP, dadurch
>> kommt zwar etwas Overhead durch die echo-Zeilen zusammen und es kostet
>> vielleicht ein wenig Performance, aber es sieht für mich einfach besser
>> aus.
>
> Ja gegeben hat es das schon vorher, aber jeder WEbdesigner der sich auch
> so nennen darf hat versucht es zu unterlassen,
> Heimwerker haben natürlich weitergemacht...

Das haben leider auch die Profis so gemacht, ich sag' nur OS-Commerce, 
XT-Commerce, PhpMyAdmin... Vielleicht auch deswegen haben die 
PostgreSQL-Entwickler für ihre Neuentwicklung ihrer Administrations-GUI 
pgAdmin3 gleich davon abgesehen, phpPgAdmin zu erweitern, und für 
pgAdmin4 gleich ein Webprogramm auf der Basis von Python und Flask 
entwickelt -- und dazu einen popeligen Miniatur-GUI-Webbrowser, der 
nurmehr diese Webseite darstellt. Große Vorteile: das Werkzeug läßt sich 
nicht nur lokal, sondern auch remote und zentralisiert installieren, und 
dank Flasks Templateengine Jinja2 kommt auch kein Mensch in die 
Versuchung, Code in Layout einzubetten.

>
1
> //fetch template und output
2
> $template = addslashes(implode('', file("template/std.tpl")));
3
> eval ("\$output = \"$template\";");
4
> echo stripslashes($output);
5
>

Bisher sind mir in meinem mehr als dreißigjährigen Leben als Entwickler 
nur fünf oder sechs Anwendungsfälle für eval()- und exec()-Funktionen 
begegnet. Sicherlich existieren noch viele mehr, aber... sei mir nicht 
böse, aber das ist ja noch viel schlimmer als die Designschwäche, die Du 
damit zu vermeiden versuchst!

> Man muss eben nur sicherstellen, dass man weiss was man da ins eval
> schickt; aber das ist ein anderes Thema;)

Genau, am Besten mit Regular Expressions... </sarkasmus>

> smarty ist mMn für die meisten Dinge aber sinnvoller als ein
> selbstgestricktes templatesystem,

Unbedingt! Oder Twig, Plates, Mustache, Blade, Volt, Dwoo... und ehrlich 
gesagt wären sogar RegExe besser als eval()!

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Nein Du missverstehst, php ist selbst keine template-engine,

Entschuldige bitte, aber es bist Du, der mißversteht. PHP ist eine 
ausgesprochen leistungsfähige Template-Engine, mißachtet jedoch eine der 
Kerneigenschaften von Template-Engines: nämlich die Beschränkung des 
Befehlsumfangs auf das, was die Autoren der Template-Engine und die 
Entwickler der Software zulassen.

> php ist eine skriptsprache spezifisch erdacht um Webseiten zu erstellen,

Nein, PHP ist eine Template-Sprache. Das erkennst Du schon daran, daß 
ohne PHP-Tags überhaupt gar nichts ausgeführt wird; ich zeig Dir das mal 
an einem Beispielskript:
1
#!/usr/bin/php
2
echo 3 * '4';
3
<?php echo 3 * '4'; ?>

Um es nachzuvollziehen, speichere den Code in einer Datei auf einem 
System, wo der defaultmäßige PHP-Interpreter unter /usr/bin/php 
erreichbar ist (prüfen kannst Du das mit "which php" in Deiner Shell), 
gib' dieser Datei Ausführrechte ("chmod +x <dateiname>") und führ es aus 
("./<dateiname>").

Die Ausgabe (bei mir mit PHP 7.2 unter Kubuntu 18.04.5 LTS) ist:
1
echo 3 * '4';
2
12

Oh, huch... Jeder(!) erfahrene Entwickler ohne PHP-Erfahrung sieht zwei 
(mitunter) tödliche Dinge: erstens, sogar bei einem PHP-Shellscript 
(!!1!elf!) wird der Code nur ausgeführt, wenn er innerhalb der 
Template-Tags "<?php" und "?>" steht. Ganz offensichtlich ist das eine 
Template-Engine, was denn sonst? Daß die auch APIs zum Zugriff auf 
Datenbanken, Dateisysteme, und so weiter hat, spielt dabei keine Rolle, 
sowas kann ich mit Jinja2 und anderen Template-Engines auch herstellen. 
Merke: was eine Template-Engine ist, bemißt sich nicht am 
Funktionsumfang, sondern an seiner Arbeitsweise. Eine Datei zu lesen, 
die mit bestimmten Auszeichnungen versehenen Teile durch generierte 
Inhalte zu ersetzen, und dann zurückzugeben, das nennt der Fachmann eine 
Template-Engine, egal ob sie ColdFusion, Text::Template, Jinja2 oder 
meinetwegen eben auch PHP heißt.

Und dann fällt dem Profi noch etwas auf: nämlich, daß sich ein String 
offenbar mit einer Ganzzahl multiplizieren läßt -- und es dabei nicht 
einmal eine Warnung oder etwas ähnliches gibt. Das ist ziemlich... 
merkwürdig für eine Sprache, die sich die Objektorientierung von 
kompilierten Sprachen wie Java oder C++ geklaut hat, mit 
Sichtbarkeitsmodifikatoren wie "public", "protected" und "private". 
Unter modernen Skriptsprachen gibt es weder den einen, noch den anderen 
Unsinn, die würden dabei natürlich eine Exception werfen.

Mit Ausnahme von Python. Unter Python würde das nicht passieren, weil es 
dort eine -- natürlich dokumentierte -- Besonderheit gibt: "3 * '4'" 
würde den String "444" zurückgeben. Das muß man zwar wissen, ist oft 
aber sehr sinnvoll und schick, wenn man Kommandozeilenprogramme zur 
Darstellung von Daten schreibt... Aber klar, sowas macht man unter PHP 
nicht, das ist ja vornehmlich für Webprogramme und nicht allzu gut für 
Kommandozeilen- oder GUI-Software geeignet. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Andre schrieb:
> Warum du so ein Fan von Template Engines bist erklärst du auch nicht.
> Ich sehe da keine Vorteile...

Nicht schlimm, dann erklär' ich's Dir.

Schau, so eine dynamische Webseite besteht üblicherweise aus sehr, sehr 
vielen Komponenten. Da gibt es HTML-, CSS- und Java/ECMAscript-Code, 
Grafiken (Bilder) sowie möglicherweise auch Videos, SVGs (HTML5 Canvas), 
Audiodaten und mehr. Im Hintergrund arbeiten dazu noch 
Softwareentwickler, Datenbänker, Sysops oder -- meinethalben -- auch 
DevOps-Fachleute. Und wenn Du eine große, verteilte Seite ausliefern 
willst, kommen auch noch Kubernetes-, OpenStack-, AWS, Azure-, GCP-, 
womöglich auch noch Heroku-Fachleute, obendrein die Spezis für 
Cloudflare und Suchmaschinenoptimierung, Marketing, Vertrieb... und dazu 
kommen dann noch die Qualitätssicherer und CI-Spezis, und, und, und. Oft 
sind das hunderte, manchmal sogar tausende Leute...

Sogar dann, wenn Du vielleicht nicht gerade in regulierten Umfeldern wie 
Behörden, Finanzunternehmen und Ähnlichen zu tun hast, möchtest Du nicht 
jedem Beteiligten einen kompletten Zugang zu allem geben.

Und natürlich möchtest Du das Layout Deiner Website von dessen 
Darstellung trennen, deswegen gibt es das MVC- und andere Patterns für 
solche Dinge.

> Variante 1: template.smarty
>> <h1>%%headline%%</h1>
>
> Variante 2: template.php
>> <h1><?php echo $headline; ?></h1>
>
> Inhaltlich machen die beiden Varianten das Gleiche.

NEIN! Für die erste Variante (template.myengine wäre besser als 
template.smarty) reichen Regular Expressions aus, mithin: die 
Angriffsoberfläche beschränkt sich primär auf das Search & Replace 
Deiner Regex-Engine.

Bei Deiner zweiten Variante hingegen wird -- und das ist der wesentliche 
Teil -- Code ausgeführt! Klar, in dem Fall nur ein "echo"... aber das 
könnte doch auch ein eval() sein, oder?

Ist Euch eigentlich bewußt, daß -- je nach Schätzung -- etwa 80 bis 90% 
aller IT-Angriffe von innen kommen?

> Aber für Variante 1
> musst du in PHP einen Parser schreiben, der die .smarty Datei ausführt
> und die Variable "headline" ausgibt.
> Das kannst du auch direkt mit Variante 2 erledigen, der PHP Parser läuft
> sowieso schon.

Das stimmt.

> P.S. in meinen wilden PHP Tagen (noch bevor das mit Objekten was
> anfangen konnte...) habe ich auch unendlich viele Stunden damit
> verbracht, mir eigene Engines zu schreiben oder mich in Smarty
> einzuarbeiten.
> Lohnt sich meiner Meinung nach alles nicht. Viel wichtiger ist ein
> stabiles Framework, das eine Datenbank Abstraktion, Sessions, Aufruf der
> Templates usw. schön kapselt. Dieses Grundgerüst muss man ja nicht jedes
> mal selbst neu erfinden.

Da gibt's ja ein paar, für jede mir bekannte Skriptsprache. Für PHP 
wären das etwa Serendipity oder Zend, für spezielle Projekte kann man 
sich das auch zusammensetzen beispielsweise mit einer der eben genannten 
Template-Engines und Doctrine (in dem tatsächlich noch ein paar Zeilen 
Code von mir stecken). Aber: ein wesentlicher Teil fast all dieser 
Frameworks ist eine anständige Template-Engine...

von sid (Gast)


Lesenswert?

Herr Sprechdurchfall.. sie scheinen übersehen zu haben, dass wir uns um 
Johannes kümmern wollen und der Exkurs in php und dessen eigenheiten 
schon zu weit ging

Sheeva P. schrieb:
> sid schrieb:
>> php ist eine skriptsprache spezifisch erdacht um Webseiten zu erstellen,
>
> Nein, PHP ist eine Template-Sprache. Das erkennst Du schon daran,
...

Man Du redest echt nur gequirlte Shice, oder?

Okay:
https://www.php.net/manual/de/intro-whatis.php
ZITAT:
> PHP (rekursives Akronym für PHP: Hypertext Preprocessor) ist eine weit
> verbreitete und für den allgemeinen Gebrauch bestimmte
> Open Source- Skriptsprache,
> welche speziell für die Webprogrammierung geeignet ist

und ja sie propagieren selbst das einbetten von php in bestehendes html 
schon im (im Link) folgenden Beispiel...
deswegen muss ich das doch nicht schön finden.

Sheeva P. schrieb:
> Bisher sind mir in meinem mehr als dreißigjährigen Leben als Entwickler
> nur fünf oder sechs Anwendungsfälle für eval()

Achwas.. ich mach den PHP-Kagg seit 1997 (erstes skript war php3 wenn 
ich mich recht erinnere) damals hiess das noch "personal home page"
Du schon seit vor 1990 ... interesseng
also mindestens FÜNF ganze Jahre länger als es PHP überhaupt gibt;
ich bin schwerst beeindruckt wie weit Du Deiner Zeit vorraus warst.
OOODer ich nehm einfach weiterhin an, dass Du ein scheisse labernder 
Blender bist ;)

'sid

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> "3 * '4'" würde den String "444" zurückgeben.
Und was ist daran besser als 12?

> <?php echo str_repeat('4',3); ?>
444

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> sie scheinen übersehen zu haben, dass wir uns um
> Johannes kümmern wollen

Habe ich.

> Sheeva P. schrieb:
>> Bisher sind mir in meinem mehr als dreißigjährigen Leben als Entwickler
>> nur fünf oder sechs Anwendungsfälle für eval()
>
> Achwas.. ich mach den PHP-Kagg seit 1997 (erstes skript war php3 wenn
> ich mich recht erinnere) damals hiess das noch "personal home page"
> Du schon seit vor 1990 ... *interesseng*
> also mindestens FÜNF ganze Jahre länger als es PHP überhaupt gibt;
> ich bin schwerst beeindruckt wie weit Du Deiner Zeit vorraus warst.
> OOODer ich nehm einfach weiterhin an, dass Du ein scheisse labernder
> Blender bist ;)

Oder Du solltest einfach mal lesen lernen, hm? Vor PHP gab es nämlich 
schon andere Sprachen, weißt Du, auch wenn Du keine kennst.

An Deinen verbalen Ausfälligkeiten sieht der geneigte Leser sicherlich 
selbst, wer hier der Blender ist. Könner haben so etwas nicht nötig.

von Sheeva P. (sheevaplug)


Lesenswert?

Ben B. schrieb:
>> "3 * '4'" würde den String "444" zurückgeben.
> Und was ist daran besser als 12?

Daß es eine dokumentierte Ausnahme in einer typsicheren Sprache ist, die 
ich nur deswegen erwähnt habe damit sie mir nicht gleich wieder ein 
Oberkluger aufs Brot schmiert. Es wird deutlicher, wenn ich das Beispiel 
etwas umformuliere.

In modernen, typisierten Sprachen wie Python oder Ruby wirft "12 / '4'" 
korrekt eine Exception, in nicht bzw. schwach typisierten Sprachen wie 
Perl oder PHP aber leider nicht. Dieses Verhalten kann zu schwierig zu 
entdeckenden logischen Fehlern führen. Auch wenn das Verhalten von Perl 
und PHP in diesen Fällen meistens das Richtige sein wird, ist das leider 
nicht garantiert. Und deswegen habe ich im Laufe der Jahre auch schon 
mehrmals gesehen, daß das zu Fehlern geführt hat.

Und andererseits ist es in einer Skriptsprache natürlich auch 
inkonsistent, nicht einmal eine Typsicherheit bei den Basistypen zu 
haben, für die Objektorientierung jedoch sogar Zugriffsmodifikatoren wie 
private, protected und public einzuführen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ich denke die beste Lösung ist, wenn der User z.B. am Anfang seines 
Programms festlegen kann, wie er das behandelt haben möchte.

Mir ist z.B. völlig egal ob "123" vom Typ String oder Integer ist, ich 
behandle sowas ausgehend vom Inhalt der Variablen und nicht von deren 
Typ. Bei übermittelten Formulardaten z.B. weiß ich ja gar nicht ob so 
eine Eingabe als String oder als Zahl gemeint ist. Da muß ich sowieso 
bereinigen und mir das passend umformen. Ich vertrete auch grundsätzlich 
die GIGO-Fraktion, wenn der User Scheiße eingibt, darf auch ruhig 
Scheiße wieder rauskommen. Als Beispiel "Gib bitte eine ganze Zahl 
ein!", der User hat 'nen Clown gefrühstückt und ich bekomme anstatt z.B. 
"123" sowas wie "eine ganze Zahl" zurück - dann ists völlig okay, wenn 
daraus einfach eine Null wird. Was besseres hat der Clown nicht 
verdient. Wenn ich das typisiere, mit floor() oder round() oder 
$x=(int)$x wirds auch nicht besser. Also muß ich in die Variable 
reinschauen, stelle fest ey da sind ja Chars drin, die keine Ziffer sind 
und dann kann ich den Clown dafür gründlich zusammenscheißen, zusammen 
mit der Aufforderung, nochmal die Schule zu besuchen und es danach 
nochmal zu probieren. Nach bestandener Prüfung ist aber eine korrekte 
Zahl in der Variable, egal von welchem Typ sie ist.

Evtl. wird es dadurch einfacher, Fehler damit zu machen als in 
typisierten Sprachen. Aber in denen müsste ich mir das halt explizit 
umwandeln und kann dabei genau so neue Fehler machen. Was davon nun 
besser sein soll weiß ich nicht. Das Thema lässt sich sowieso nicht 
abschließend klären - weil was soll man z.B. mit dem Integer "3l1t3 
h4xx0r" machen? True, weil Inhalt? False, weil kein Integer? Null? 3? 
313? 31340? Viel Spaß! :)

von sid (Gast)


Lesenswert?

Sheeva P. schrieb:
> Oder Du solltest einfach mal lesen lernen, hm? Vor PHP gab es nämlich
> schon andere Sprachen, weißt Du, auch wenn Du keine kennst.

Och doch die ein oder andere schon..
Aber wir unterhalten uns eben nicht über Cobol Fortran oder Haskell,
wir (und auch Du) reden in diesem Gesprächsfaden AUSSCHLIESSLICH von 
php, und auch wenn ich die Ausrede von Dir -dass Du ja gaaaarnicht von 
php sprichst- erwartet hab muss ich doch sagen, dass sie schon unfassbar 
plump ist.

Und ja, ich bin es fürchterlich leid mich mit Flachpfeifen wie Dir zu 
rumzuärgern, die für jeden Ihrer Brainfarts die passende Ausrede 
bereithalten, weil sie gewohnt sind Ausreden aus dem Hut zu ziehen aus 
Mangel an Kompetenz.

Und es stimmt, ich werde dann auch ausfallend, was etwas unfair ist, 
denn Teile davon hat nicht Deine Inkompetenz sondern die eines Anderen 
verursacht;
jemand der (kurioserweise zu sehr ähnlichem Thema) meinte aufbegehren zu 
müssen und es so geschafft hat durch seine "Verbesserung"
ein produktives System ungefragt nahezu lahm zu legen und statt 
zurückzurudern hat er dann zu allem Überfluss kaputtrepariert.
Und man hatte der Ausreden... sein Arbeitgeber prüft grade ob eine 
fristlose Kündigung machbar ist des entstandenen Schadens wegen.

Nundenn.. eval hat sehr viel Sinn in sehr speziellen Fällen.
(unabhängig der [mir bekannten] Programmiersprachen)
Minder viel Sinn in deutlich mehr und nahezu keinen Sinn in fast allen 
andern Fällen ... korrekt soweit.
bei feststehenden templates mit fixen Variablen (um die es hier geht)
hat eval keinen nennenswerten Nachteil (abgesehen mal von zumeist 
vernachlässigbaren Performanceeinbußen)
Also lass mich mich in der strahlenden Sonne deiner übermenschlichen 
Weisheit baden,
und erzähl mal wesegen Du glaubst eval wäre hier schlecht?
Bedenke dabei dass das template unveränderlich und die zu ersetzenden 
Variablen darin plausibilitäts- und inhaltsgepüft zugefüttert werden.
Und wir weder über c-derivate noch java noch Sonstwas sprechen, sondern 
ausschliesslich über php.

UND LOS!
(man bin ich gespannt auf die Ausrede wieso Du das nicht erklären 
kannst)

'sid

von Sheeva P. (sheevaplug)


Lesenswert?

Ben B. schrieb:
> Ich denke die beste Lösung ist, wenn der User z.B. am Anfang seines
> Programms festlegen kann, wie er das behandelt haben möchte.

Äh... der User oder der Entwickler? ;-)

> Mir ist z.B. völlig egal ob "123" vom Typ String oder Integer ist, ich
> behandle sowas ausgehend vom Inhalt der Variablen und nicht von deren
> Typ. Bei übermittelten Formulardaten z.B. weiß ich ja gar nicht ob so
> eine Eingabe als String oder als Zahl gemeint ist. Da muß ich sowieso
> bereinigen und mir das passend umformen.

Wenn es nur um einfache Formulardaten ginge... aber wenn man es schon 
richtig macht und eine Template-Engine wie Smarty (für PHP) oder Jinja2 
(für Python) benutzt, ist es meistens viel sinnvoller und auch 
einfacher, seine Formulare mit so etwas wie HTML_QuickForm2 (für PHP) 
oder WTForms (für Python) zu benutzen. Da hat man nämlich alles unter 
einem Dach: die Definition der Formularfelder mit Defaults, Feinheiten 
der HTML-Ausgabe, Validierung der Felder und des gesamten Formulars, 
Konvertierung der übergebenen Werte in die korrekten Datentypen, alles 
an genau einer einzigen Stelle zusammengefaßt und überschaubar, und 
natürlich wiederverwendbar.

Problematischer hingegen wird es mit Software, die Daten aus unbekannten 
Quellen und mit unbekannten Strukturen verarbeiten muß. Denk' 
beispielsweise an hochgeladene CSV-Dateien, dabei kann so viel Unsinn 
passieren (und wenn man öfter mit dem Format arbeitet, erschreckt einen 
der hohe Anteil sogar von erfahrenen IT-Profis, die keine korrekten 
CSV-Dateien erstellen oder parsen können).

> Ich vertrete auch grundsätzlich
> die GIGO-Fraktion, wenn der User Scheiße eingibt, darf auch ruhig
> Scheiße wieder rauskommen. Als Beispiel "Gib bitte eine ganze Zahl
> ein!", der User hat 'nen Clown gefrühstückt und ich bekomme anstatt z.B.
> "123" sowas wie "eine ganze Zahl" zurück - dann ists völlig okay, wenn
> daraus einfach eine Null wird. Was besseres hat der Clown nicht
> verdient.

Für diesen Standpunkt hatte ich in den Anfangszeiten des WWW, als ich 
noch CGIs in C geschrieben habe, gewisse Sympathien, mittlerweile aber 
nicht mehr. Entweder man validiert und konvertiert einen Datensatz 
vollständig und korrekt, oder es ist ein Fehler zu werfen und dem 
Benutzer so anzuzeigen, daß er ihn selbst beheben kann.

Ist eben auch so eine Sache von Clean Code, einem sauberen Userinterface 
und der Usability meiner Software. Ich habe an mich selbst den hohen 
Anspruch, ordentliche und professionelle Arbeit abzuliefern, sogar wenn 
es am Anfang nur so ein kleines Popelprojektchen für mich selbst ist. 
Und die anfänglich paar Minuten Mehraufwand, es von vorneherein richtig 
zu machen, sparen mir im Zweifelsfall ein mehrstündiges Refactoring und 
häufig hohe Aufwände für Support und Debugging.

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Sheeva P. schrieb:
>> Oder Du solltest einfach mal lesen lernen, hm? Vor PHP gab es nämlich
>> schon andere Sprachen, weißt Du, auch wenn Du keine kennst.
>
> Och doch die ein oder andere schon..
> Aber wir unterhalten uns eben nicht über Cobol Fortran oder Haskell,
> wir (und auch Du) reden in diesem Gesprächsfaden AUSSCHLIESSLICH von
> php, und auch wenn ich die Ausrede von Dir -dass Du ja gaaaarnicht von
> php sprichst- erwartet hab muss ich doch sagen, dass sie schon unfassbar
> plump ist.

Wenn Du meine Beiträge gelesen hättest, wäre Dir sicherlich aufgefallen, 
daß ich mehrfach auf andere Skriptsprachen wie Python, Perl, und Ruby 
verwiesen habe. Insofern: lern endlich lesen, ja?

> Und ja, ich bin es fürchterlich leid mich mit Flachpfeifen wie Dir zu
> rumzuärgern, die für jeden Ihrer Brainfarts die passende Ausrede
> bereithalten, weil sie gewohnt sind Ausreden aus dem Hut zu ziehen aus
> Mangel an Kompetenz.

Ich brauche gar keine Ausreden, und übrigens auch keine Beleidigungen. 
Ich habe Argumente. Daß Du sie nicht verstehen kannst oder willst, liegt 
nicht an mir.

> und erzähl mal wesegen Du glaubst eval wäre hier schlecht?
> Bedenke dabei dass das template unveränderlich und die zu ersetzenden
> Variablen darin plausibilitäts- und inhaltsgepüft zugefüttert werden.
> Und wir weder über c-derivate noch java noch Sonstwas sprechen, sondern
> ausschliesslich über php.

Auch mit PHP kann man viele unschöne Dinge tun, zum Beispiel Dateien mit 
sensiblen Informationen lesen, löschen, oder den Server mit einer 
Fork-Bombe DoSen. Weißt Du, ich hab' schon viel zu häufig erlebt, daß 
ein genialer Entwickler geglaubt hat, er könnte mit ein paar RegExen hie 
und da eine korrekte und sichere Validierung von etwas durchführen, das 
am Ende ausführbarer Code wird. Ganz davon abgesehen, daß sogar Profis 
häufig... sagen wir, nicht sehr gut mit Regular Expressions können.

Auch SQL Injection hat im Kern ähnliche Ursachen, und trotz aller 
Bemühungen der Entwickler kommt so etwas immer und immer und immer 
wieder vor. (Einer der Gründe, weshalb ich beim Umgang mit SQL-RDBMS 
grundsätzlich zur Verwendung eines OR-Mappers rate, und wenn das 
ausnahmsweise nicht möglich sein sollte, dann wenigstens dazu, die zu 
den üblichen SQL-Treibern gehörigen Quoting-Funktionen zu nutzen, statt 
die Queries manuell zusammen zu klöppeln.)

Die Gefährlichkeit von eval() ist der Grund, weshalb in der 
Dokumentation von PHP's eval()-Funktion auch gleich ganz oben eine 
ausführliche Warnung steht und Profis so etwas scheuen wie der Teufel 
das Weihwasser. Zumal PHPs Infrastruktur für so etwas wie eine 
Validierung auch nicht besonders gut geeignet ist; Python zum Beispiel 
ist da deutlich besser aufgestellt (Funktionen compile(), eval() und 
exec() mit global- und local-Parametern, Module parser, ast, und 
RestrictedPython).

Nun, in den meisten Umgebungen, in denen ich arbeite, sind die, die Code 
schreiben und für dessen Sicherheit verantwortlich sind, sehr selten 
dieselben, die auch die Templates schreiben. Und wenn man sich dann vor 
Augen führt, daß je nach Schätzung etwa 80% aller IT-Angriffe von innen 
kommen, und manche Webdesigner durchaus auch fähige Entwickler sind...

Sorry, mir ist sowas zu heikel, insbesondere für eine Aufgabe, für die 
es bereits fertige, sehr leistungsfähige, vielfach getestete und 
produktionsreife Software wie Smarty oder Twig gibt. Es ist aus meiner 
Sicht schlicht unprofessionell und dumm, für so einen Fall ohne Not 
selbst etwas zu bauen, und das gilt ganz besonders dann, wenn man dazu 
auch noch mit extrem heiklen Konstrukten wie eval() herumhantiert. 
Außerdem ist die Implementierung einer eigenen Template-Engine bei 
gleichzeitiger Verfügbarkeit von leistungsfähigen, getesteten und 
stabilen Lösungen natürlich mal wieder ein klassischer Fall von NIH -- 
not invented here.

Aber mach's halt, wie Du willst, halt Dich für den Größten und pöbele 
alle an, die diese Deine Ansicht nicht teilen. Du bist für Deinen Code 
verantwortlich, wie ich das für den meinen bin.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Äh... der User oder der Entwickler? ;-)
Ja wie nennt man nun den Benutzer einer Programmiersprache ......
Okay, ich merke schon, daß Du mich nicht verstehen willst.

Auf den Rest gehe ich daher nicht weiter ein, da hast Du ja auch schon 
viel weggelassen ... mit Dir über sowas zu diskutieren führt zu nichts.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Ben B. schrieb:
>> Äh... der User oder der Entwickler? ;-)
> Ja wie nennt man nun den Benutzer einer Programmiersprache ......

Naja... den Entwickler, oder?

> Okay, ich merke schon, daß Du mich nicht verstehen willst.

Eigentlich habe ich mir Mühe gegeben.

> Auf den Rest gehe ich daher nicht weiter ein, da hast Du ja auch schon
> viel weggelassen ... mit Dir über sowas zu diskutieren führt zu nichts.

Schade, denn... eigentlich versuche ich ja zu vermitteln, was Clean Code 
ist. Und tatsächlich habe ich bei Dir auch das Gefühl, daß die Mühe 
nicht verloren wäre.

von sid (Gast)


Lesenswert?

Sheeva P. schrieb:
> Weißt Du, ich hab' schon viel zu häufig erlebt, daß
> ein genialer Entwickler geglaubt hat, er könnte mit ein paar RegExen hie
> und da eine korrekte und sichere Validierung von etwas durchführen, das
> am Ende ausführbarer Code wird.

sowas sieht man allüberall.. korrekt

Aber ich hab noch keine regular expression gebraucht für n template 
dieser Art..
Usereingaben sind da suchqueries und das Ergebniss der Suche landet aus 
der Datenbank im template das query selber nicht...
wenn da ein Bösewicht schafft mir in die Testikel zu kneifen, dann in 
der Aufbereitung des Suchquery, nicht im eval stage des templates.
und suchqueries aufbereiten muss man so oder so.
(da sind dann in der tat auch Reg-Exen drin hauptsächlich um ein attempt 
log zu schreiben ;))

Naja ich hab 15 Jahre ein System betreut dass alles 'schlimme' 
implementiert hat.. evaluierte templates, shell_exec für backend tasks, 
user file upload
und bei 200000+ usern inkl diverser Tunichtgute gab es sehr wohl mehr 
als nur einen Versuch für ein SQL oder shellscript inject, da wurden 
Dinge hochgeladen mein lieber Scholli (polymorpher php code.. geiles 
Konzept wusste garnicht dass das so geht) und dennoch -abgesehen von 
zwei erfolgreichen DDos Attacken- war das System niemals kompromittiert.

Ich hab's eingangs erwähnt
sid schrieb:
> Man muss eben nur sicherstellen, dass man weiss was man da ins eval
> schickt;
> aber das ist ein anderes Thema;)

Wenn man das weiss, seh ich im eval absolut kein Risiko.
Das Risiko entsteht durch UNWISSENHEIT,
blindlinks Zeug zu evaluieren ist dumm,
schlimmer blindlinks usereingaben in shell_exec zu schicken.
Aber aufgrund einer usereingabe ein vodefiniertes Tool mit 
vordefinierten parametern zu starten
um dessen Ausgabe dem user dann zu präsentieren ist vollends harmlos
man muss halt nur wissen was man tut.


Sheeva P. schrieb:
> Sorry, mir ist sowas zu heikel, insbesondere für eine Aufgabe, für die
> es bereits fertige, sehr leistungsfähige, vielfach getestete und
> produktionsreife Software wie Smarty oder Twig gibt. Es ist aus meiner
> Sicht schlicht unprofessionell und dumm, für so einen Fall ohne Not
> selbst etwas zu bauen, und das gilt ganz besonders dann, wenn man dazu
> auch noch mit extrem heiklen Konstrukten wie eval() herumhantiert.

Smarty.class.php (irgend'ne alte 2.6.16 vom lokal-horst)
1
/**
2
     * wrapper for eval() retaining $this
3
     * @return mixed
4
     */
5
    function _eval($code, $params=null)
6
    {
7
        return eval($code);
8
    }
9
    /**#@-*/

für unprofessionell und dumm halte ich diejenigen die sich 
ausschliesslich auf das zusammenkopieren von fertigprodukten beschränken 
aus Mangel an Kompetenz EIGENES zu kreieren.

Sicherlich, will man ein ein zuverlässiges Produkt an den Kunden 
übergeben, MUSS MAN WISSEN WAS MAN TUT oder man gerät schnell in Teufels 
Küche.
Ich hab mein kinkerlitzchen template evaluierungsdings in einigen 
Scripten auf einigen Seiten verbraten und noch keine Beschwerden 
bekommen;
ich gebe Dir aber recht, dass ich bei grösseren Projekten selber auch 
lieber smarty nutze (wie oben angemerkt) eben weil es vollständiger html 
aus php entfernen kann und teile der redundanzen übernimmt, das caching 
schnell sinn macht usw.usf.

bei statischen Seiten mit simpelster CMS Funktion.. eval eval evval..
RISIKOFREI! (ich mach das lange genug um da Garantie für geben zu 
können)

Aber so ist das, die Einen verkaufen ihren Kunden Wordpress Mist die 
anderen nicht ;)

'sid

von Berufsberater (Gast)


Lesenswert?

Wer fummelt den heute noch sein Frontend mit PHP zusammen? Ob Templates 
oder nicht, das ist beides Asbachuraltmässig.
Das wird mit REACT oder Angular gemacht oder SAP Fiori wenn SAP hinten 
dran hängt, dahinter hockt dann ein Service der die Daten annimmt, mit 
was der implementiert wurde ist praktisch wurscht, nen REST-Service 
geniert man sich heute mit Swagger oder anderen Tools je nach Sprache. 
Wer das alles von Hand zusammenfummeln will hat vermutlich auch nie was 
von Testing gehört und klickt das selber in den Formularen rum.
Leute wir haben 2020 nicht 1995, Webentwicklung läuft heute anders als 
vor 100 Jahren, vor allem vieles automatisiert und testbar, auch 
automatisch.
Hier ist wohl wieder das Stümpertreffen der HTML-Altherrenmannschaft von 
1995.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Hach ja, wegen solcher Meinungen liebe ich Berufs- oder 
Unternehmensberater, ganz besonders gerne in Verbindung mit BWL.

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Sheeva P. schrieb:
>
> Aber ich hab noch keine regular expression gebraucht für n template
> dieser Art..
> Usereingaben sind da suchqueries und das Ergebniss der Suche landet aus
> der Datenbank im template das query selber nicht...
> wenn da ein Bösewicht schafft mir in die Testikel zu kneifen, dann in
> der Aufbereitung des Suchquery, nicht im eval stage des templates.
> und suchqueries aufbereiten muss man so oder so.
> (da sind dann in der tat auch Reg-Exen drin hauptsächlich um ein attempt
> log zu schreiben ;))

Verzeihung, aber oben hatte ich noch den Eindruck, Du würdest mit dem 
eval()-Zeug ein ganzes Templatesystem schreiben wollen... Im Übrigen 
könnte ein fieser Finger einem dabei natürlich mit passenden 
Datenbankinhalten in die Testikel kneifen.

> Naja ich hab 15 Jahre ein System betreut dass alles 'schlimme'
> implementiert hat.. evaluierte templates, shell_exec für backend tasks,
> user file upload
> und bei 200000+ usern inkl diverser Tunichtgute gab es sehr wohl mehr
> als nur einen Versuch für ein SQL oder shellscript inject, da wurden
> Dinge hochgeladen mein lieber Scholli (polymorpher php code.. geiles
> Konzept wusste garnicht dass das so geht) und dennoch -abgesehen von
> zwei erfolgreichen DDos Attacken- war das System niemals kompromittiert.

Da hast Du Glück gehabt. Bei Kunden habe ich schon eine Reihe 
kompromittierter Systeme gesehen, obwohl die sich pedantisch und 
penibelst an die einschlägigen Richtlinien und Sicherheitsempfehlungen 
gehalten haben... Sei mir nicht böse, aber irgendwie habe ich gewisse 
Schwierigkeiten damit, Stichproben mit einer Größe von exakt 1 auch nur 
als statistische Evidenz anzusehen. ;-)

> Ich hab's eingangs erwähnt
> sid schrieb:
>> Man muss eben nur sicherstellen, dass man weiss was man da ins eval
>> schickt;
>> aber das ist ein anderes Thema;)
>
> Wenn man das weiss, seh ich im eval absolut kein Risiko.

Aber wie will man das wissen? Überprüfst Du manuell jedes Template, das 
Deine Designer ins VCS gepusht haben? Alles, was aus Deiner Datenbank 
kommt?

> Das Risiko entsteht durch UNWISSENHEIT,
> blindlinks Zeug zu evaluieren ist dumm,
> schlimmer blindlinks usereingaben in shell_exec zu schicken.

Es war noch nie ein valides Argument für schlimme Dinge, daß es noch 
schlimmere Dinge gibt. ;-)

> Sheeva P. schrieb:
>> Sorry, mir ist sowas zu heikel, insbesondere für eine Aufgabe, für die
>> es bereits fertige, sehr leistungsfähige, vielfach getestete und
>> produktionsreife Software wie Smarty oder Twig gibt. Es ist aus meiner
>> Sicht schlicht unprofessionell und dumm, für so einen Fall ohne Not
>> selbst etwas zu bauen, und das gilt ganz besonders dann, wenn man dazu
>> auch noch mit extrem heiklen Konstrukten wie eval() herumhantiert.
>
> Smarty.class.php (irgend'ne alte 2.6.16 vom lokal-horst)
>
1
> /**
2
>      * wrapper for eval() retaining $this
3
>      * @return mixed
4
>      */
5
>     function _eval($code, $params=null)
6
>     {
7
>         return eval($code);
8
>     }
9
>     /**#@-*/
10
>

Das ist in der aktuellen 2er-Version (2.6.31) von Smarty immer noch 
drin, aber: das ist eine interne Hilfsfunktion, mit welcher zuvor 
kompilierter Template-Code ausgeführt wird. Auch in Version 3 nutzen die 
Entwickler an mehreren Stellen die eval()-Funktion, aber -- und das ist 
der Punkt: um ihren vorher kompilierten Code auszuführen. Also nicht 
einfach etwas, das aus einer nichtvertrauenswürdigen Quelle wie einer 
einfachen Templatedatei oder einer Datenbank kommt, in die auch Benutzer 
schreiben können, sondern etwas, das zuvor durch deren Compiler gelaufen 
ist. Wenn bei dieser Art, eval() zu benutzen, etwas schief läuft, dann 
ist das Problem nicht die eval()-Funktion, sondern deren Compiler... ;-)

> für unprofessionell und dumm halte ich diejenigen die sich
> ausschliesslich auf das zusammenkopieren von fertigprodukten beschränken
> aus Mangel an Kompetenz EIGENES zu kreieren.

Naja, "Zusammenkopieren von Fertigprodukten"... sagen wir mal so: ich 
habe leider schon häufig erleben müssen, daß "Entwickler" sich aus 
öffentlichem Code irgendwas zusammenkopiert und es ein bisschen 
abgewandelt haben, um die Funktionalität zu bekommen, ohne die 
Lizenzbedingungen der betreffenden Software beachten zu müssen. So etwas 
ist natürlich grober Unfug und völlig unprofessionell.

Aber andererseits gibt es einen riesigen Haufen von fertiger Software, 
die stabil, ausgereigt und tausendfach getestet ist. So etwas selbst 
nachzuimplementieren, oft aus der Hybris heraus, es besser zu können als 
Leute, die soetwas seit zig Jahren machen, ist ein klassisches NIH. Wir 
würden ja auch nicht auf die Idee kommen, uns einen eigenen Webserver, 
eine eigene Datenbanksoftware oder eine eigene Volltext-Suchmaschine zu 
schreiben, weil das einerseits unglaublich aufwändig wäre, wir das Zeugs 
hinterher ständig pflegen und warten müßten, und die Wahrscheinlichkeit 
sehr groß ist, daß wir all die Fehler und Probleme, die Apache, Nginx, 
PostgreSQL, oder Elasticsearch schon gemacht haben, nur noch einmal 
wiederholen würden.

Bei meinem aktuellen Arbeitgeber ging es darum, für einen 
Telekommunikationsladen eine Art... Personensuchmaschine zu 
implementieren, also inklusive unscharfer Namenssuche (trotz 
Damerau-Levenshtein, Beider-Morse, und ähnlichen Möglichkeiten immer 
noch ein sehr schwieriges Problem). Ich habe dann binnen zwei Tagen 
einen Prototypen mit Python und Elasticsearch entwickelt, den wollten 
meine Chefs aber nicht und haben einen Kollegen darangesetzt, soetwas 
mit Lucene in unsere eigene Software einzubauen. Und siehe da, nach vier 
Wochen war der Kollege dann soweit, seine Lösung wurde ausgeliefert und 
der Kunde war zufrieden...

Zwei Wochen später kam dann das nächste Gespräch mit dem Kunden, und 
plötzlich war er gar nicht mehr so zufrieden. Klar, die Software meines 
Kollegen tat, wie ihr geheißen, aber plötzlich wollte der Kunde mehr: 
Scores für die Treffer, weitere Suchfelder, und noch ein paar andere 
Dinge, die ich vergessen habe. Mit meinem Prototypen hatte ich die neuen 
Anforderungen in zwei Stunden eingebaut, aber mein armer Kollege hat 
dann wieder drei Wochen gehackt. Und ich wette, sobald ein neuer Kunde 
mit ähnlichen Anforderungen kommt, muß der arme Kerl wieder 'ran...

Die Leute von Elasticsearch und Lucene hingegen machen seit Ewigkeiten 
nichts als Volltextsuche, viele von ihnen sind Autoren von allerlei 
wissenschaftlichen Papers zu diesem Thema, und sie arbeiten und forschen 
aktiv daran. Deswegen bringt diese fertige Software bereits einen 
riesigen Haufen von Funktionen mit, die mein armer Kollege sich allesamt 
erst ausklamüsern und für unseren Kunden zugänglich machen muß, wo ich 
einfach meinen JSON-Suchquery, die internen Datenstrukturen und meine 
Formularklassen ändern kann und sonst schon alles habe, was ich brauche.

> ich gebe Dir aber recht, dass ich bei grösseren Projekten selber auch
> lieber smarty nutze (wie oben angemerkt) eben weil es vollständiger html
> aus php entfernen kann und teile der redundanzen übernimmt, das caching
> schnell sinn macht usw.usf.

Ich würde es schon deswegen nehmen, weil es eine stabile und sehr gut 
getestete Software ist. Die mir im Zweifelsfalle viel mehr nützliche 
Funktionen bietet, als ich momentan brauche, die aber, siehe mein 
vorheriges Beispiel, spätestens dann hilfreich sind, wenn meine Software 
in die nächste Iteration ihres Lebenszyklus gehen sollte.

> bei statischen Seiten mit simpelster CMS Funktion.. eval eval evval..
> RISIKOFREI! (ich mach das lange genug um da Garantie für geben zu
> können)

Sorry, aber... ich weiß ja, nach Larry Wall ist Hybris eine 
Kardinaltugend von Programmierern, aber mit solchen Argumentationen habe 
ich echt ein Problem.

> Aber so ist das, die Einen verkaufen ihren Kunden Wordpress Mist die
> anderen nicht ;)

Tja, ich kann meinen Kunden gar kein Wordpress verkaufen. Das würde ja 
erfordern, daß ich auf meinen Servern PHP installiere, und... sorry, 
nein. Ich kenne PHP und viele damit implementierte Projekte zu gut, um 
mir das anzutun. ;-)

von sid (Gast)


Lesenswert?

Sheeva P. schrieb:
> Verzeihung, aber oben hatte ich noch den Eindruck, Du würdest mit dem
> eval()-Zeug ein ganzes Templatesystem schreiben wollen...

Nicht ganz
ich wollte diesen dreizeiler durch ein eigenes templatesystem ersetzen..
da ich aber mehr und mehr funktionen eingebaut hatte die ich 
'gewöhnlich' auch in smartys engine nutzte, machte es irgendwann keinen 
Sinn mehr und es war in der Tat sinnvoller direkt smarty 
weiterzunutzen.. zumindest für jetzt.
Die engine beruhte aber auch in Teilen darauf,
dass die tpl files durch einen eval schritt liefen
(noch vollkommen getrennt von Usereingaben)
nur zur filterung der if/then/else/foreach Zeilen,
daraus wurd dann ein temporärer compiler gestrickt der die daten in html 
formatiert passend und in an die jeweiligen Stellen kopiert
(line inserts, da meine Priorität auf caching lag)

Sheeva P. schrieb:
> Im Übrigen
> könnte ein fieser Finger einem dabei natürlich mit passenden
> Datenbankinhalten in die Testikel kneifen.

Nur wenn man die Usereingaben nicht ordentlich validiert ;)
Was letzenendes in der Datenbank landete unterstand ja ebenfalls meinem 
Einfluss ;)

Sheeva P. schrieb:
> Da hast Du Glück gehabt. Bei Kunden habe ich schon eine Reihe
> kompromittierter Systeme gesehen, obwohl die sich pedantisch und
> penibelst an die einschlägigen Richtlinien und Sicherheitsempfehlungen
> gehalten haben... Sei mir nicht böse, aber irgendwie habe ich gewisse
> Schwierigkeiten damit, Stichproben mit einer Größe von exakt 1 auch nur
> als statistische Evidenz anzusehen. ;-)

Neja, das ist nicht nur Glück..
Glück dass ich einen Pentester beschäftigte der mindestens auf Augenhöhe 
mitmischen konnte und Glück, dass die Anzahl derer die besser sind in 
Bösewichtereien als er gering genug war und keiner von jenen 'mich' 
wahrnahm.. jo
Oder schlau genug mir einen pentester zu suchen der diesem Kriterium 
entsprach und sich fröhlich weiterbildete um mir möglichst fest auf die 
Zehen zu treten bevor der Code beim Kunden landete.
(wenngleich nach ein paar Jahren er immer weniger Chance zum treten 
fand.. man lernt halt dazu ;))

Sheeva P. schrieb:
> Also nicht
> einfach etwas, das aus einer nichtvertrauenswürdigen Quelle wie einer
> einfachen Templatedatei oder einer Datenbank kommt,

HUST.. wenn ICH der Auto des Datenbankinhalts und der AUtor des 
templates bin... wenn ich mir nciht vertraue, wem denn sonst?

Sheeva P. schrieb:
> Aber wie will man das wissen? Überprüfst Du manuell jedes Template, das
> Deine Designer ins VCS gepusht haben? Alles, was aus Deiner Datenbank
> kommt?

Selbstverständlich geht kein nicht verifiziertes template je online, ich 
bin doch nicht irre!
Die meisten sind selbstgehäkelt (ja von designern), oder kommen (wenn 
der Kunde so wünschte)
aus einer html template quelle (themeforest oder bestehende webseite 
oder oder) und werden dann
händisch für den Kunden zu einem template für system xyz umgeschrieben.
Und selbstredend wird jede ausgelieferte Zeile Code geprüft, inkl der 
templates und selbst sachen von Drittanbietern
sind geprüft jquery und co werden zB niemals von drittquellen geladen 
sondern immer nur vom eigenen server um deren Inhalt unmodifiziert zu 
wissen.
Der Kunde kann nichtmal was in die Datenbank schreiben was schadhaften 
Einfluss nehmen könnte, dazu sind die Regeln zu strikt.
(so in etwa wie du hier im Forum vermutlichst nichts schadhaftes in ein 
post schreiben könntest)

Sheeva P. schrieb:
> So etwas selbst
> nachzuimplementieren, oft aus der Hybris heraus, es besser zu können als
> Leute, die soetwas seit zig Jahren machen

Naja ich mache das ja seit zig jahren (wenn auch knapp)
Es ging mir hier nicht um 'besser' es ging hier um 'angepasster'.
Und ein eigene System hätte für mich eben den immensen Vorteil,
dass ich mich um Lizenzen nicht scheren müsste;
manchmal verlangt der Autor die Nennung, was prinzipiell völlig in 
Ordnung geht.
Aber findet man dann doch ne Sicherheitslücke, dann ist jene Nennung so 
gut wie eine Einladung an die Schergen, dann ist's auch blöd.
UNd bei grossen Projekten noch zusätzlich eine zweites/drittes grosses 
'Fremdprojekt' zu überprüfen und zwar mit jeder xten Version erneut ist 
doch ein bisschen teuer, und wenngleich ein Kunde anteilig für die 
Überprüfung zahlen muss, naja... ich will denen halt auch nicht grundlos 
Geld aus der Tasche ziehen.

Ich verlasse mich nicht darauf, dass es auf tausend Seiten läuft,
9,9 von 10 Seiten die ein Sicherheitsleck hatten schreiben sich das ja 
nicht auf deren Homepage, nes pas?
Meistens erfährt man es dann MONATE später und dann könnte es zu spät 
sein.

Sheeva P. schrieb:
> also inklusive unscharfer Namenssuche
hehe die PEST in Tüten... man wie mich das nervt wenn man
"Hellen Hunt" sucht und "Höllen Hund" findet weil Suchmaschinen jeden 
Buchstaben anzweifeln wollen.
Aber ja, das ist wie Wordpress... jeder will es und keiner weiss warum!

Sheeva P. schrieb:
> nach Larry Wall ist Hybris eine
> Kardinaltugend von Programmierern, aber mit solchen Argumentationen habe
> ich echt ein Problem.

Nuja, wie gesagt Software die ich ausliefere ist getestet..
und wenn da ein Sicherheitsrisiko besteht wird sie so nicht 
ausgeliefert.
Falls ein Sicherheitsleck nach der Auslieferung bekannt wird (dem Kunden 
vor dem Ausliefern eines Patch/Fix) und "ich" das ich hätte vermeiden 
können*, dann bekommt der Kunde sein Geld zurück.
Ich finde der Kunde muss sich darauf verlassen können,
dass das was er kauft auch funktioniert
das halte ich nicht für Hybris, das halte ich für faires 
Geschäftsgebaren.
Der Kunde verlässt sich auf mein Produkt und es ist an mir dem Gerecht 
zu werden.

* Hat der Kunde sein Passwort auf den Monitor geklebt
oder Quantencomputer machen einen Fortschritt der es erlaubt benutzte 
(als sicher angenommene) Verschlüsselungsverfahren zu knacken etc. bin 
ich raus...
aber mein Fehler..-> mein Schaden.

Deswegen können Kunden bei mir auch nicht drängeln (das heisst sie 
dürfen, ist aber Erfolglos) SORGFALT geht halt nicht gut unter 
Zeitdruck.
Und Geld/Arbeitszeit verschenken will ich nu auch nicht.

Sheeva P. schrieb:
> Ich kenne PHP und viele damit implementierte Projekte zu gut, um
> mir das anzutun. ;-)
PHP ist da wie python... wenn man weiss was man tut ist es dufte,
falls nicht kann beides mehr Ärger machen als einem lieb sein kann.
(ich mag die python syntax nicht sonderlich.. aber das ist un wirklich 
ein gaaanz anderes Thema)

In diesem Sinne

'sid

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Aber findet man dann doch ne Sicherheitslücke, dann ist jene Nennung so
> gut wie eine Einladung an die Schergen, dann ist's auch blöd.

Security by obscurity?

> Nuja, wie gesagt Software die ich ausliefere ist getestet..
> und wenn da ein Sicherheitsrisiko besteht wird sie so nicht
> ausgeliefert.

Heartbleed, Shellshock, Meltdown...

> PHP ist da wie python...

Nein, sicher nicht.

von René H. (mumpel)


Lesenswert?

Ich nutze bei meiner Homepage auch PHP-Templates. Allerdings an meinen 
Internet-Auftritt angepasst (habe ich mir machen lassen). Allerdings 
nutze ich keine Datenbanken, sondern muss neue Inhalte manuell 
einpflegen. Angriffspunkte wie bei Joomla & Co.  gibt es daher nicht 
(bis auf den FTP-Zugang, aber den hat bisher keiner geknackt). Ich kann 
nicht nachvollziehen, weshalb hier Templates "verteufelt" werden.

von René H. (mumpel)


Lesenswert?

Ben B. schrieb:
> Hach ja, wegen solcher Meinungen liebe ich Berufs- oder
> Unternehmensberater, ganz besonders gerne in Verbindung mit BWL.

Ja, so wie Sodbrennen. 😁

von sid (Gast)


Lesenswert?

Sheeva P. schrieb:
> Security by obscurity?

denn das ist doch wieder ein fürchterlich albernes Argument.
steht auf der letzten von Dir gepflegten Homepage welcher Code im 
Hintergrund läuft? Ich denke nicht.
Stell Dir vor euer telekommunikationskonzern müsste bei Deiner version 
die pythonversion angeben,
welches elasticsearch läuft, ob maria/my oder postgres SQL
ob und wenn ja welches phpmyadmin panel installiert ist etc pp..
der würd sich schwer bedanken... und den Auftrag an wen anders vergeben.
ich schreib auch nicht meinen Namen unten ran, was viele Klitschen gerne 
tun,
aus zwei Gründen.. erstens kauft der Kunde sich keienn Werbepatch von 
mir
zweitens siehe oben! wird eine Lücke in meinem Code entdeckt, muss ich 
ja keine Einladungen verschicken sie zu exploiten.

Sheeva P. schrieb:
> Heartbleed, Shellshock, Meltdown...
exakt.. wo ich nix für/gegen kann muss ich nicht für/wegen gradestehen..

heartbleed ist n prima Beispiel

Sheeva P. schrieb:
> andererseits gibt es einen riesigen Haufen von fertiger Software,
> die stabil, ausgereigt und tausendfach getestet ist. So etwas selbst
> nachzuimplementieren, oft aus der Hybris heraus, es besser zu können als
> Leute, die soetwas seit zig Jahren machen, ist ein klassisches NIH.

dass es auch viele wide-spread-use Software gibt die dann eben doch n 
bug hat.
und wolltest Du auf deiner webseite dann stehen gehabt haben
"powered by OpenSSL v1.0.1b" ?? Auch nicht, oder?
Eben..!
Ich würde darauf verzichten wollen um wenigstens die Zeit zu erkaufen 
den patch zu installieren.

Glücklicherweise ist selbst OpenSSL aber schon nichtmehr wirklich Teil 
unseres Aufgabenbereichs.
Wir haben weder was mit der Hardware nich dem LinuxDerivat noch mit dem 
Apache NGinx und oder dessen modulen zu tun.
Wir installieren das auf Kundenwunsch und nach Absprache aber
"nach bestem Wissen und Gewissen" als Dienstleistung
eben weil man sich nicht durch nochmal ne halbe million Zeilen Code mehr 
fressen kann.

Sheeva P. schrieb:
> Nein, sicher nicht.
doch doch.. perl, php, dart, python, ruby.. alles dergleiche Käse,
bisschen Langsam, bisschen weniger gut aber unfassbar nützlich wenn man 
damit umzugehen weiss

'sid

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Sid ... magst Du nicht lieber etwas Grafik machen? :)

von Sheeva P. (sheevaplug)


Lesenswert?

René H. schrieb:
> Ich nutze bei meiner Homepage auch PHP-Templates. Allerdings an meinen
> Internet-Auftritt angepasst (habe ich mir machen lassen). Allerdings
> nutze ich keine Datenbanken, sondern muss neue Inhalte manuell
> einpflegen. Angriffspunkte wie bei Joomla & Co.  gibt es daher nicht
> (bis auf den FTP-Zugang, aber den hat bisher keiner geknackt). Ich kann
> nicht nachvollziehen, weshalb hier Templates "verteufelt" werden.

Es werden keine Templates "verteufelt". Ganz im Gegenteil verweise ich 
darauf, daß die eval()-Funktion ausgesprochen gefährlich und es deswegen 
sinnvoll ist, so weit wie nur irgend möglich auf deren Nutzung zu 
verzichten. Im Falle von Templating-Funktionalität ist das auch 
überhaupt gar nicht schwierig, denn für PHP existieren ja ausgereifte 
und gut getestete Template-Engines wie Smarty, Twig oder Volt.

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Sheeva P. schrieb:
>> Security by obscurity?
>
> denn das ist doch wieder ein fürchterlich albernes Argument.
> steht auf der letzten von Dir gepflegten Homepage welcher Code im
> Hintergrund läuft? Ich denke nicht.

Zugegeben, nicht auf der Seite selbst, sondern im zugehörigen 
Github-Repository. Da finden sich auch die Docker- und Compose-Dateien, 
aus denen hervorgeht, in welchen Versionen die Komponenten des 
zugrundeliegenden Technologiestacks genutzt werden.

> Sheeva P. schrieb:
>> Heartbleed, Shellshock, Meltdown...
> exakt.. wo ich nix für/gegen kann muss ich nicht für/wegen gradestehen..

Wenn mein Kunde oder mein Arbeitgeber nachfragen, warum seine 
Kundendaten gerade im Darknet aufgetaucht sind und die Kripo mit einem 
richterlichen Durchsuchungsbeschluß vor der Türe steht, weil jemand 
seine Server zur Verteilung von gecrackter Software, Kinderpr0ns und für 
Angriffe auf andere Plattformen mißbraucht... aus irgendeinem Grund habe 
ich gewisse Schwierigkeiten, zu glauben, daß er sich mit einem "da kann 
ich aber leider nix dafür und stehe nicht dafür gerade" zufrieden geben 
wird. Aber möglicherweise sind Deine Kunden da verständnisvoller.

> dass es auch viele wide-spread-use Software gibt die dann eben doch n
> bug hat.

Das stimmt zwar, aber ich halte die Wahrscheinlichkeit, daß eine gut 
abgehangene Software einen ausnutzbaren Fehler hat, für deutlich 
geringer, als daß meine eigene Software einen solchen Fehler hat. Vor 
dann, wenn ich in meiner Software Funktionen benutze, von deren Nutzung 
sogar deren Entwickler klar und deutlich abraten.

> Sheeva P. schrieb:
>> Nein, sicher nicht.
> doch doch.. perl, php, dart, python, ruby.. alles dergleiche Käse,
> bisschen Langsam, bisschen weniger gut aber unfassbar nützlich wenn man
> damit umzugehen weiss

Da gibt es signifikante Unterschiede, aber das ist eine andere 
Geschichte und soll ein andermal erzählt werden.

von René H. (mumpel)


Lesenswert?

Sheeva P. schrieb:
> denn für PHP existieren ja ausgereifte und gut getestete
> Template-Engines wie Smarty, Twig oder Volt.

Die einzigen fertigen Templates die ich nutze sind PHPMailer, 
Semantic-UI und einen Syntax-Highlighter. Der Rest ist speziell an meine 
Befürfnisse angepasst (das Kontaktformular habe ich teilweise selber 
angepasst, was nicht leicht ist wenn man kein englisch kann und sich 
deshalb durch die englischsprachigen Workshops "mogeln" muss).

von sid (Gast)


Lesenswert?

Ben B. schrieb:
> Sid ... magst Du nicht lieber etwas Grafik machen? :)

LOOOL DU hast ja recht!

ich such glaich nochmal den sch* loginkram.. muss sich ja irgendwo 
verstecken

'sid

von sid (Gast)


Lesenswert?

sid schrieb:
> ich such glaich

oh sorry... das kommt davon wenn man nebenher mit Kumpels textet..
gleich kann ich schon schreiben nur em' ned wenn man glaichzeitsch 
dyslexiert ;).

'sid

von sid (Gast)


Lesenswert?

Sheeva P. schrieb:
> Zugegeben, nicht auf der Seite selbst, sondern im zugehörigen
> Github-Repository. Da finden sich auch die Docker- und Compose-Dateien,
> aus denen hervorgeht, in welchen Versionen die Komponenten des
> zugrundeliegenden Technologiestacks genutzt werden.

Naja ich lese gerne quer bei github, aber Zeug dass ich mir von Kunden 
teuer bezahlen lasse stell ich eigentlich nicht ins Internetz...
Spannedes Konzept es anders zu machen.

Sheeva P. schrieb:
> Wenn mein Kunde oder mein Arbeitgeber nachfragen, warum seine
> Kundendaten gerade im Darknet aufgetaucht sind und die Kripo mit einem
> richterlichen Durchsuchungsbeschluß vor der Türe steht, weil jemand
> seine Server zur Verteilung von gecrackter Software, Kinderpr0ns und für
> Angriffe auf andere Plattformen mißbraucht... aus irgendeinem Grund habe
> ich gewisse Schwierigkeiten, zu glauben, daß er sich mit einem "da kann
> ich aber leider nix dafür und stehe nicht dafür gerade" zufrieden geben
> wird. Aber möglicherweise sind Deine Kunden da verständnisvoller.

Naja, aber das ist ja als wolltest Du den Hersteller Deines Autos 
verklagen,
weil ein Autodieb damit auf der Flucht nach Rumänien ne Oma todgefahren 
hat.
Und ich verkaufe nichtmal Autos, ich verkaufe das "Entertainmentsystem" 
und beheizbare Sitze (manchmal Lack, Verglasung und Lenkräder) ;)
Und ja - um die Metapher totzureiten - unsere Werkstatt kann auch 
Bremsflüssigkeit und Ölstand kontrollieren;
und wenn man so ganz bei Null anfangen muss empfehlen wir auch mal ein 
bestimmtes Auto zu kaufen
aber wenn da die Zylinderkopfdichtung reisst ist unser Lack halt 
ungemein selten schuld ;)

'sid

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Sheeva P. schrieb:
>> Zugegeben, nicht auf der Seite selbst, sondern im zugehörigen
>> Github-Repository. Da finden sich auch die Docker- und Compose-Dateien,
>> aus denen hervorgeht, in welchen Versionen die Komponenten des
>> zugrundeliegenden Technologiestacks genutzt werden.
>
> Naja ich lese gerne quer bei github, aber Zeug dass ich mir von Kunden
> teuer bezahlen lasse stell ich eigentlich nicht ins Internetz...
> Spannedes Konzept es anders zu machen.

Kundenwunsch. Machen etliche OSS-Projekte allerdings auch so.

> Sheeva P. schrieb:
>> Wenn mein Kunde oder mein Arbeitgeber nachfragen, warum seine
>> Kundendaten gerade im Darknet aufgetaucht sind und die Kripo mit einem
>> richterlichen Durchsuchungsbeschluß vor der Türe steht, weil jemand
>> seine Server zur Verteilung von gecrackter Software, Kinderpr0ns und für
>> Angriffe auf andere Plattformen mißbraucht... aus irgendeinem Grund habe
>> ich gewisse Schwierigkeiten, zu glauben, daß er sich mit einem "da kann
>> ich aber leider nix dafür und stehe nicht dafür gerade" zufrieden geben
>> wird. Aber möglicherweise sind Deine Kunden da verständnisvoller.
>
> Naja, aber das ist ja als wolltest Du den Hersteller Deines Autos
> verklagen, weil ein Autodieb damit auf der Flucht nach Rumänien
> ne Oma todgefahren hat.

Abgesehen davon, daß sich um sowas natürlich eine Staatsanwaltschaft 
kümmert, ist zwar nicht alles, was hinkt, ein Vergleich... Dieser hinkt 
dafür aber gleich auf beiden Füßen. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

René H. schrieb:
> Sheeva P. schrieb:
>> denn für PHP existieren ja ausgereifte und gut getestete
>> Template-Engines wie Smarty, Twig oder Volt.
>
> Die einzigen fertigen Templates die ich nutze sind PHPMailer,
> Semantic-UI und einen Syntax-Highlighter. Der Rest ist speziell an meine
> Befürfnisse angepasst (das Kontaktformular habe ich teilweise selber
> angepasst, was nicht leicht ist wenn man kein englisch kann und sich
> deshalb durch die englischsprachigen Workshops "mogeln" muss).

Verzeihung, aber ich fürchte, Du meinst mit "Template" etwas anderes als 
die anderen Teilnehmer dieses Gesprächs. Wir verstehen darunter 
HTML-Dateien mit Platzhaltern, die dann mit Daten aus anderen Quellen 
gefüllt werden. Ein Beispiel-Template:
1
<h1>Hallo {{ name }}</h1>

Mit dem Datensatz "name='René'" gerendert, kommt dann
1
<h1>Hallo René</h1>

heraus. Ich bin mir nicht ganz sicher, aber Du scheinst unter "Template" 
hingegen eher so etwas wie eine Bibliothek, ein Modul oder ein Package 
zu meinen...?

von René H. (mumpel)


Lesenswert?

Sheeva P. schrieb:
> Ich bin mir nicht ganz sicher, aber Du scheinst unter "Template"
> hingegen eher so etwas wie eine Bibliothek

Unter anderem. Unter Template verstehe ich eine Vorlage, auf die ein 
Dokument aufbaut.

von sid (Gast)


Lesenswert?

Sheeva P. schrieb:
> Abgesehen davon, daß sich um sowas natürlich eine Staatsanwaltschaft
> kümmert

Du fängst schon wieder an gequirlte Kagge zu labern

Erst heist's, dass ich meinen Kunden auf meinen Code eine Garantie 
geben kann ist allein meiner übersteigerten Hybris zu verdanken,
dann heisst es Du lieferst ausschliesslich Code aus,
der 100% bulletproof ist und ich würde meinen Kunden Kinderp0rnos 
unterjubeln unwissentlich, weil ich eben keine Garantie für Code 
übernehmen kann den ich nicht selber geschrieben noch vollständig 
duchgearbeitet habe.
(Du aber schon oder wie??)

Also kurz: entweder Du hast eine noch übersteigerte Hybris als Du mir 
vorwirfst,
oder Du bist ein noch dümmerer Dummschwätzer als ich Dir vorwerfe zu 
sein

'sid

von Sheeva P. (sheevaplug)


Lesenswert?

sid schrieb:
> Sheeva P. schrieb:
>> Abgesehen davon, daß sich um sowas natürlich eine Staatsanwaltschaft
>> kümmert
>
> Du fängst schon wieder an gequirlte Kagge zu labern

Verzeihung, aber Du hast mit irgendwelchen hahnebüchenen "Vergleichen" 
mit einem Autodiebstahl und überfahrenen Großmüttern angefangen.

> Erst heist's, dass ich meinen Kunden auf meinen Code eine Garantie
> geben kann ist allein meiner übersteigerten Hybris zu verdanken,

Nein. Daß Du Deinem Kunden eine Garantie gibst, obwohl Du gefährliche 
Befehle nutzt und deren Eingabedaten kaum korrekt validieren kanns, das 
ist die Hybris.

> dann heisst es Du lieferst ausschliesslich Code aus,
> der 100% bulletproof ist und

Nein. Ich liefere Code aus in dem Bewußtsein, daß auch meine Software 
nicht ohne Fehler ist. Entsprechend gestalte ich meine Software- und 
Systeminfrastruktur so defensiv und tiefgestaffelt wie irgend möglich, 
und meide den Gebrauch heikler Konstrukte, vor denen sogar deren eigene 
Entwickler ausdrücklich warnen.

> ich würde meinen Kunden Kinderp0rnos unterjubeln unwissentlich,

Das habe ich nicht gesagt. Aber sei unbesorgt: darum kümmern sich dann 
schon die, die in Deinen Server einsteigen.

> weil ich eben keine Garantie für Code
> übernehmen kann den ich nicht selber geschrieben noch vollständig
> duchgearbeitet habe.

Selbst wenn Du Fremdcode vollständig durchgearbeitet hast, wirst Du 
keine Garantie dafür übernehmen können. Denn das kannst Du sogar für 
Deinen eigenen Code genau so wenig, wie ich das für meinen kann.

> (Du aber schon oder wie??)

Nein. Ich kann garantieren, daß ich mein Bestmögliches getan, und mich 
zumindest an den Stand der Technik und die best common practices 
gehalten habe, und daß ich mir die größtmögliche Mühe gegeben habe, 
sorgfältig zu arbeiten.

Du hingegen bestehst immer noch darauf, eval() zu benutzen, dessen 
Entwickler ausdrücklich in der Dokumentation zu dieser Funktion 
schreiben:

"*Achtung* Das eval()-Sprachkonstrukt ist sehr gefährlich, weil es die 
Ausführung von beliebigem PHP-Code erlaubt. Seine Verwendung wird daher 
nicht empfohlen. Wenn sorgfältig überprüft wurde, dass es keine andere 
Möglichkeit gibt als dieses Konstrukt zu verwenden, ist besonders darauf 
zu achten keine von Nutzern bereit gestellten Daten zu übergeben ohne 
diese zuvor ordnungsgemäß zu validieren."

Dem Erfinder von PHP, Rasmus Lerdorf, wird das folgende Zitat über diese 
Funktion zugeschrieben:

"If eval() is the answer, you're almost certainly asking the wrong 
question."

Dieses Dein Vorgehen, das in meinen Augen ein eklatanter Widerspruch zu 
den best common practices und dem Stand der Technik ist, verteidigst Du 
nun damit, daß OpenSSL und andere Drittsoftware durchaus Fehler gehabt 
hat.

Dabei ignorierst Du geflissentlich den einen oder anderen Sachverhalt, 
vor allem, daß es hier gar nicht um OpenSSL geht. Zudem werden OpenSSL 
und andere wichtige Libraries regelmäßig von erfahrenen Fachleuten 
auditiert, was bei Deinem Code vermutlich nicht passiert. Die Juristen 
haben für so etwas den Fachbegriff der "Fahrlässigkeit" (§ 276 Abs. 2 
BGB) definiert.

Hinzu kommt, daß Dein Code nichts anderes macht als die vorhandenen, gut 
getesteten Template-Engines, und es daher keinen Anlaß sowie auch keinen 
Vorteil gibt, sowas in Produktionscode selbst zu implementieren -- schon 
gar nicht unter Verwendung von bekannt unsicheren Funktionen. Ein 
alternatives Verhalten, namentlich die Nutzung einer der etablierten 
Template-Engines, wäre Dir also zumutbar gewesen.

Deine... Gegen-"Argumentation" beschränkt sich leider darauf, mich als 
Dummkopf zu beschimpfen, mir Dinge zu unterstellen, die ich nie gesagt 
habe, dann auf seltsame Autodiebstahlsvergleiche sowie letztendlich 
darauf zu verweisen, das Software von Dritten schließlich auch Fehler 
enthalte. Ach so, und obendrein kamen auch noch die wiederholten 
unsachlichen Haßtiraden über Wordpress -- sowie natürlich der wichtige 
Hinweis, daß auf Deinem Server noch nie was passiert sei. Als ob das 
eine Garantie dafür sei, daß auch in Zukunft nie etwas passiert.

Ich habe kein Wort von Dir darüber lesen dürfen, welchen wichtigen Grund 
es gegeben haben soll, entgegen der Warnungen des PHP-Entwicklerteams 
eine unsichere Funktion wie eval() zu benutzen. Im Grunde habe ich 
überhaupt nichts von Dir gelesen, in dem ich auch nur eine Ähnlichkeit 
mit einem sachlichen Argument hätte sehen können. Und jetzt, nach diesem 
meinem Hinweis, ist es auch zu spät dafür.

Denn, weißt Du, mir reicht es jetzt. Ich hätte nicht gedacht, daß ich im 
Jahre 2020 noch mit einem Webentwickler über Sicherheit diskutieren 
müßte. Und mich obendrein noch als Dummkopf diffamieren lassen müßte, 
weil ich zu sorgfältiger Arbeit sowie zur Vermeidung eines bekannt 
unsicheren Konstrukts rate. Ich wünsche Dir jedenfalls noch einen 
schönen Tag und viel Erfolg auf Deinem weiteren Lebensweg.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Login-Kram noch nicht gefunden? ;)

Meine nur, ich hab den Login-Kram inzwischen fertig, hab mich dafür 
entschieden das übergeblendete Fenster in einen Frame/DIV-Container zu 
laden und man kann schon zwischen den (allerdings noch leeren) Sektoren 
springen. Und ich hab bislang auch kein Problem mit PHP in HTML oder 
andersrum.

von Sheeva P. (sheevaplug)


Lesenswert?

René H. schrieb:
> Sheeva P. schrieb:
>> Ich bin mir nicht ganz sicher, aber Du scheinst unter "Template"
>> hingegen eher so etwas wie eine Bibliothek
>
> Unter anderem. Unter Template verstehe ich eine Vorlage, auf die ein
> Dokument aufbaut.

Puh... Okay, aus der Perspektive von Klassen- und Funktionstemplates in 
C++ könnte ich das vielleicht noch irgendwie verstehen, und tatsächlich 
bedeutet das englische "Template" ja auch nicht mehr als "Vorlage". 
C++-Templates sind am Ende ja nichts anderes als Vorlagen zur Erzeugung 
von Klassen und Funktionen -- die dann am Ende zum Beispiel in einer 
Bibliothek wie der Standard Template Library (STL) oder den bekannten 
Boost-Libraries gebündelt werden können.

Im Kontext dieser Diskussion geht es bei dem Begriff Template aber um 
eine weitaus weniger weit gefaßte Definition. Nämlich um 
Dokumentvorlagen, die Platzhalter und womöglich eine einfache Logik 
enthalten, damit die Template-Engine aus dem Template und dazu passenden 
Daten zum Beispiel ein HTML-Dokument erzeugen kann.

Du nanntest als ein Beispiel für ein Template den PHPMailer. Das ist 
aber zunächst einmal eine Codebibliothek, die es ermöglicht, Deine Daten 
als E-Mail über SMTP zu versenden. Richtig ist, daß die Daten, also etwa 
der Betreff und der Inhalt Deiner E-Mail, mit einer Template-Engine aus 
einem Template generiert werden können. Aber das macht PHPMailer noch 
nicht zu einer Template-Engine oder gar einem Template im Sinne der hier 
geführten Diskussion.

von Sheeva P. (sheevaplug)


Lesenswert?

Ben B. schrieb:
> Login-Kram noch nicht gefunden? ;)
>
> Meine nur, ich hab den Login-Kram inzwischen fertig, hab mich dafür
> entschieden das übergeblendete Fenster in einen Frame/DIV-Container zu
> laden und man kann schon zwischen den (allerdings noch leeren) Sektoren
> springen. Und ich hab bislang auch kein Problem mit PHP in HTML oder
> andersrum.

Ben? Hallo? Bist Du noch bei uns? Was möchtest Du uns mit Deinem Beitrag 
sagen?

(Nebenbei: was, bitte, ist ein Frame/DIV-Container?)

[Edit: Added Höflichkeit 0.2.]

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Sheeva aus purer Höflichkeit rede ich über PHP/HTML nicht mehr mit Dir.
Der, für den das ist, weiß schon Bescheid denke ich.

Mit Frame/DIV-Container meine ich einen IFrame, der mittels DIV-Element 
über eine andere Seite drübergeblendet werden kann, so daß man zwei 
voneinander unabhängige Seiten übereinander erhält.

Natürlich wirst Du mir jetzt wieder vorhalten, daß IFrames sowas von

[ ] oldschool
[ ] lame
[ ] dumm
[ ] verboten
[ ] .................................................

sind und daß Du tausend "bessere" Ansätze dafür kennst ... und weißt Du 
was ...? Geht mir am Arsch vorbei - mindestens einen Meter für jeden 
Ansatz den Du besser findest.

von Sheeva P. (sheevaplug)


Lesenswert?

Ben B. schrieb:
> Mit Frame/DIV-Container meine ich einen IFrame, der mittels DIV-Element
> über eine andere Seite drübergeblendet werden kann, so daß man zwei
> voneinander unabhängige Seiten übereinander erhält.
>
> Natürlich wirst Du mir jetzt wieder vorhalten,

Nö. Das ist schließlich nicht sicherheitsrelevant. ;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.