PHP Inhalte bei Seiten und News

[sxp2high]

Hallo,

hab hier schon danach gesucht, aber leider nichts gefunden.

Ich würde gerne wissen, wie ich PHP in den Seiten und News benutzen kann!

Danke schon mal!

Edit:
Ich weiss mittlerweile, dass ich mit Code Seiten PHP kompatible Abschnitte einbetten kann. Ich würde aber auch gerne PHP Variablen im WYSIWYG benutzen...

[Hans>NULL]

Der Editor verhindert das. Also mit 'nem anderen Editor versuchen oder mal auf den FCK-Seiten gucken.
Gruß, Hans>NUL

[mr-fan]

oder wenns nicht so viel html is eine seite mit code einbauen php rein und einen abschnitt code2 (gibts bei den addons) das html rein, hab allerdings noch nicht ausprobiert obs die var übernimmt! glaub aber ned das das abblockt...

mfg martin

[sxp2high]

Danke für eure Hilfe. Leider finde ich auf der Seite vom FCK nichts, genauso wenig bei TinyMCE... 

mr-fan - Du meinst ich soll den HTML Code mit echo Darstellen? Die Idee hatte ich auch schon, wäre aber eine eher unschöne Lösung.

[BerndJM]

Hi,

um der "echo und escape Wüste" zu entgehen, gibt es in PHP die sogenannte heredoc-Syntax
eine recht nette Angelegenheit um viel HTML und paar Variablen komfortabel einzugeben.
Lies mal hier -> http://www.php-space.info/php/space/heredoc-syntax.php
oder hier -> http://de.php.net/manual/de/language.types.string.php#language.types.string.syntax.heredoc

Grüßle Bernd

[Hans>NULL]

@sxp2high
Sehr oft scheitert die Suche, weil man u.U. an den "richtigen" Schlüsselbegriffen vorbeisaust.
Leider hab' ich im Moment keine Zeit an der direkten Lösung zu arbeiten, aaaaaaaaaaaber
man kann im FCK-Editor "user defined tags" oder auch "smarty php tags" nutzen. Vielleicht gibt's ja hier ein paar Anwender, die sich damit schon beschäftigt haben und helfen können.   (Ich selbst hab' zwar "irgendwo" so'n Schnipsel rumliegen, aber in welchem Projekt das jetzt liegt.... ähm...)
Gruß, Hans>NUL

Edit: Oder Du arbeitest Dich mit den Schlüsselbegriffen heran und teilst dann das Ergebnis mit. Das Thema kommt hier nämlich regelmäßig und ist -soweit ich weiß- bisher ergebnisoffen.

[Hans>NULL]

Nochmal gesucht und gefunden, eine Notiz:
In fckconfig.js // FCKConfig.Protected Source.Add( /<\?[\s\S]*?\?>/g ) ;    // PHP style server side code aktiviert.
PHP-Code läßt sich jetzt einfügen, ist nachgeprüft im Quelltext zu sehen, wird aber von WB nicht geparst. (als separate Datei sehr wohl)
Vorerst in keiner Prioritätenliste.
-------------------------------------------------
So wie das aussieht, ist da möglicherweise das WB-Team gefragt.

Der PHP-Code wurde übrigens "wild" im HTML-Modus und nicht per "user defined tag" eingefügt.

Gruß, Hans>NUL

[sxp2high]

Danke für deine Bemühungen!

Die Zeile sieht ja recht vielversprechende aus, in der fck config. Habe es selber mal getestet, aber wie du schon sagtest wird es wohl nicht geparst von seitens WB. Wirklich schade.

Werde aber noch etwas rum experimentieren...

[ruebenwurzel]

Hallo,

kann mir jemand mal erklären, warum man in einem Textbereich php parsen muss? Sehe da keinen richtigen Sinn dahinter.

Was jetzt schon machbar ist, dass man eine code section nutzt und dadrin kann php code + text (mit echo) ausgeben. Damit sollte für den Seitenberich das ganze zumindest kein Problem mehr darstellen.

Auch ist es durch mehrer Sections jederzeit möglich nach einem WYSIWYG Bereich einen Code Bereich anzuhängen und danach wieder mit WYSIWYG weiterzumachen.

Matthias

[sxp2high]

Ich möchte eben gerne Variablen im Text benutzen.

Und HTML mit echo darstellen ist bei 300 und mehr Zeilen ziemlich umständlich!   

[Hans>NULL]

Man muß doch nicht über den Sinn oder Unsinn einer Funktion eines Editors/Plugins debattieren, wenn's in WB nicht funktioniert. Der Editor hat eine Funktion, die in WB nicht funktioniert, aus welchen Gründen auch immer, in anderen CMS möglicherweise aber ohne Komplikationen ist. Es werden ja auch andere Funktionen des Editors per config. (css/xml) empfohlen, aktiviert  und genutzt, ohne Sinnfragen zu stellen. Komischerweise wird die Sinnfrage häufig dann gestellt, wenn in WB etwas NICHT funktioniert. Entweder ist das hier eine Community oder ein Kader, der bestimmt was "richtig oder falsch" ist.
Mittlerweile hat mir jemand aus unserem Team nicht erklärt, aber ein wenig nahegebracht, warum das in WB NICHT funktionieren kann, man müßte sowas wie ein Helferscript einbauen, damit es auch WB rafft. So, oder ähnlich, bin kein PHP'ler.
Es ist doch kein Beinbruch, wenn das ein oder andere nicht funktioniert. Aber erkären sollte man es, statt über Sinn oder Unsinn zu reden.
Aufgrund der Fehler in eigenen Installationen sind wir mittlerweile fast soweit, daß wir einen Fork erstellen, und uns selbst um Fehlerbereinigungen kümmern (sind es doch wirklich nur ganz wenige). Die Fachleute sind ja vorhanden. Eigentlich ein Unding bei den wenigen Installationen. Doch da wir keine Module nutzen könnte es der schnellere Weg zu Lösungen sein.
Gruß, Hans>NUL

Nachtrag an @sxp2high
Wichtig und nicht zu vergessen ist, daß durch die Aktivierung der o.a. Zeile u.U. Code-injection möglich ist/wird. Geeignete regex sind also zu verwenden. Das ganze natürlich nur wenn's im CMS auch funktioniert.

[Hans>NULL]

@sxp2high
Anscheinend kann man zur Zeit auch kein Ticket für die Angelegenheit starten
http://projects.websitebaker.org/websitebaker2/
Gruß, Hans>NUL

Nachtrag: Danke DOC
Projects/SVN server transfer

[thorn]

Hallo,

Eingaben, die in ein Editor-Feld gemacht werden, werden grundsätzlich als (HTML)-Text betrachtet. Der PHP-Interpreter bekommt die nie zu Gesicht.

Was man dafür brauchen würde, wäre ein (weiterer) Output-Filter, ähnlich dem E-Mail-Filter, der die gesamte Ausgabe (eines Modules oder der ganzen Seite) nochmal durch eval() schickt.

Ich möchte mir jetzt aber nicht ausmalen welche Möglichkeiten sich dadurch für XSS/HTML-Injektion ergeben würden 

thorn.

[Hans>NULL]

@thorn
Dank für die Aufklärung
 

....Output-Filter....nochmal durch eval() schickt.

ist wohl das was die Kollegen aus dem Team angesprochen hatten bzw. meinten.
Der Gefahr von Code-Injection, hab' jetzt nochmals vertieft in Dokus geschaut, scheint man allein mit regex nur eingeschränkt begegnen zu können und ist wohl eher als grober Schutz zu sehen. Mit jedem Satz der Dokus (Dank Hilfe meiner Teamkollegen, die mich manchmal auch "auf den Topf" setzen) lernt man dazu...
Gruß, Hans>NUL

[bjoern]

moin, sorry, dass ich mich da nun als absoluter php noop reinschraub, da ich eine Erklärung suche, warum ich bei der News selection mit dem php Abruf [TITLE] im Contentbereich keinen Erfolg habe und eben nur "[TITLE]" (nicht die eigentliche Headline) angezeigt wird..!?
was mich aber verwirrt, ist, dass [MODI_DATE] bzw. [MODI_TIME] kein Problem darstellt und richtig ausgegeben wird.

So wie ich Eure Diskussion verstehe, könnte es mit Eure Analyse zumindest teilweise eine Erklärung sein... oder liegt mein Problem an einer ganz anderen Stelle?

[thorn]

Hallo,

da das Thema wohl recht interessant - und öfter gefragt ist (über 300 Aufrufe dieses Threads in 10 Tagen) - hab ich mir zum Test mal folgendes überlegt:

in /modules/fckeditor/wb_config/wb_fckconfig.js diese Zeile ergänzen

Code:

FCKConfig.ProtectedSource.Add( /<\?[\s\S]*?\?>/g ) ;    // PHP style server side code

Das ist nötig, damit der FCKEditor überhaupt <?php-tags im Quelltext zuläßt.
Nun kann man in der Editor-Ansicht in den Quelltext wechsel, und dort php-Blöcke in der Form

<p>Und er sagte: <?php $spruch_des_tages='"Tach auch!"'; echo $spruch_des_tages; ?>, und ging fort!</p>

angeben.
Damit das nun auch ausgewertet wird, braucht es noch einen eval()-Aufruf.

Dafür in /framework/frontend_functions.php an Stelle von diesem Block

Code:

// highlights searchresults
if (isset($_GET['searchresult']) AND is_numeric($_GET['searchresult']) AND !isset($_GET['nohighlight'])) {
  if (isset($_GET['sstring']) AND !empty($_GET['sstring']) ){
    $arr_string = explode(" ", $_GET['sstring']);
    if($_GET['searchresult'] == 2) {
      // exact match
      $arr_string[0] = strtr($arr_string[0], "_"," ");
    }
    ob_start(); //start output buffer
    require(WB_PATH.'/modules/'.$module.'/view.php');
    $foo = ob_get_contents();    // put outputbuffer in $foo
    ob_end_clean();             // clear outputbuffer
    echo search_highlight($foo, $arr_string);
  }
} else {
  require(WB_PATH.'/modules/'.$module.'/view.php');
}

dies einfügen

Code:

// use eval on allowed modules
$eval_allowed_modules = array('wysiwyg');
ob_start(); // fetch original content
require(WB_PATH.'/modules/'.$module.'/view.php');
$content = ob_get_contents();
ob_end_clean();
if(in_array($module, $eval_allowed_modules)) {
  if(preg_match('#<\?php#',$content)) {
    ob_start(); // fetch 'evaluated' content
    eval('?>'.$content);
    $content = ob_get_contents();
    ob_end_clean();
  }
}
// highlights searchresults
if(isset($_GET['searchresult']) && is_numeric($_GET['searchresult']) && !isset($_GET['nohighlight']) && isset($_GET['sstring']) && !empty($_GET['sstring'])) {
  $arr_string = explode(" ", $_GET['sstring']);
  if($_GET['searchresult']==2) { // exact match
    $arr_string[0] = strtr($arr_string[0], "_"," ");
  }
  echo search_highlight($content, $arr_string);
} else {
  echo $content;
}

Und schon lüppt dat.
Die Funktion ist zur Sicherheit erstmal auf das WYSIWYG-Modul beschränkt.


Probleme:

1) in der HTML-Ansicht des FCKEditor ist der PHP-Code nicht sichtbar, und könnte leicht gelöscht, verschoben werden. Beim obigen Beispiel sieht man z.B. nur

Und er sagte , und ging fort!

das mag etwas verwirren.

2) die eval()-Funktion arbeitet im aktuellen Variablen-Namensraum (variable-scope) der Funktion page_content().
Es ist leicht möglich, Variablen, die in page_content() benutzt werden, zu überschreiben. --> absolut tödlich!
Verschiebt man den eval()-Aufruf dagegen in eine eigene Funktion, stehen wichtige Variablen nicht mehr zur Verfügung (page_id, section_id, $database, ...?). --> hier müsste man prüfen, inwiefern man die per 'global' heran holen kann.

3) Werden auf der Seite auch durch User erzeugte Inhalte angezeigt (Kommentare, z.B.), wäre es denkbar (bei einer Sicherheitslücke) das in den Kommentar eingeschleuster Schadcode im eval()-Aufruf zur Ausführung kommt. --> das Modul müßte genau geprüft werden!

4) irgendwas wollte ich noch sagen, es fällt mir aber gerade nicht mehr ein. 


Sicherheit:

Bei Modulen dir nur eigene Inhalte anzeigen scheint mir das kein Sicherheitsproblem zu sein. (Solange man dann im PHP-Code keine eigenen Lücken aufreist). Bei Modulen die auch fremde Inhalte anzeigen (alles mit eigener Kommentarfunktion, Gästebuch, und Ähnliches) sollte man wohl ehr die Finger davon lassen. Darum habe ich in der obigen Beispiel-Implementierung auch die eval-Funktion erstmal auf das WYSIWYG-Modul beschränkt ($eval_allowed_modules).

Meinungen?


thorn.

[Hans>NULL]

Die Funktion ist zur Sicherheit erstmal auf das WYSIWYG-Modul beschränkt

Ist im Blick auf die Sicherheit vielleicht auch sinnvoll nur für WYSIWYG und nach Prüfung auch NEWS für diese Erweiterung zu nutzen.

in der HTML-Ansicht des FCKEditor ist der PHP-Code nicht sichtbar

Das sehe ich nicht als Problem, da es nicht die Schreiberlinge sondern die Coder sind, die
z.B. zusätzliche Text-Funktionen einfügen möchten. Den Schreiberlingen muß man nur erzählen, wo sie drauf zu achten haben.        

Eine Frage: Ist es bei Nutzung von  "user defined tags" im Editor (für vordefinierte Funktionen) möglich die entsprechenden regex (Erlaubnis) darauf anzuwenden, so daß nicht jeglicher freigewählter Code zur Anwendung kommen kann?

Oder anders: Kann die außer Kraft gesetzte Sperre in der FCKconfig statt Zeichen bzw. Zeichenkombinatione n nicht Funktionen freigeben? Also $ich will alles, und nur das kann auch im Editor eingesetzt werden, odä so...  mal ganz naiv gefragt.

Gruß, Hans>NUL

[vyni]

Hallo zusammen,
bisher war das gottseidank kein Thema bei meinen Projekten.
Aber auch ich Ahnungsloser lese da mit. Dabei kam mir folgende Vorgehensweise in den Sinn - sagt mir bitte ob das kompletter Schwachsinn ist oder eine brauchbare Alternative.

Den FCK zumindest temporär davon abhalten, den komletten Inhalt innerhalb <p></p> zu setzen, sondern einfach zu stoppen, wo ich aufhöre was einzugeben.
Dann eine neue section (code, code2) einsetzen und den code reinhauen.
Anschließend mit wysiwyg-section fortfahren.

Somit wäre der php-code auch im backend deutlich sichtbar.

Ob sowas einfacher oder schwieriger zu realisieren ist kann ich nicht beurteilen - da seid ihr gefragt.

Gruss aus HImberg

[thorn]

Hallo,

@vyni:
Ich glaube nicht, dass man das dem FCKEditor so einfach abgewöhnen kann. Meistens wird man dieses Verhalten (automatisches Erzeugen von <p> oder <div>) ja auch haben wollen, denke ich.

@Hans>NULL:
Man könnte sich anstelle der <?... ?> eigene Fantasy-Tags überlegen (#<<... >># oder so), das würde aber nicht wirklich was ändern. Konfigurierbar? -> bringt auch nicht wirklich was, weil die meisten dann dann die Default-Werte benutzen.
Und Einschränkung auf bestimmte Funktionen? Äh, ne. Ich möchte nicht wissen, was für regex-Monster man da bauen müßte... 

thorn.

[StefanRSA]

Thanks Thorn...

In short... If I make the changes as desrcibed above, will I be able to add variables on the editor?
I tried to follow the German threat of this subject but my translator is not clear enough...

[thorn]

In short... If I make the changes as desrcibed above, will I be able to add variables on the editor?

Yes.

You will have to use "<?php"-tags
<? won't work.

<p>Hello, you are on page: <?php echo $page_id; ?>.</p>
<?php
  $tmp = array('one', 'two', 'three');
 ?>
<p>more text</p>
<table>
<?php
  foreach($tmp as $t) {
  echo "<tr><td>$t</td></tr>";
  }
?>
</table>

[StefanRSA]

Make sense! Thanks!!!