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).
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.
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
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) ;)
> 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? ;)
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
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.
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!
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!
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 ;-)
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
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.
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:
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
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.
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.
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.
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
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...
;-)
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
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! ;-)
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.
>
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()!
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
<?phpecho3*'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. ;-)
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...
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
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.
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.
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ß! :)
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
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.
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.
> Ä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.
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.
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
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.
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. ;-)
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
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.
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.
Ben B. schrieb:> Hach ja, wegen solcher Meinungen liebe ich Berufs- oder> Unternehmensberater, ganz besonders gerne in Verbindung mit BWL.
Ja, so wie Sodbrennen. 😁
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
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.
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.
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).
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
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
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
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. ;-)
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...?
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.
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
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.
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.
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.
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.]
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.
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. ;-)
Thread beobachten
Seitenaufteilung abschalten