Vorschau für künftigen Eintrag

[Timbalu]

Äh, wo hast Du das genau gemacht?

Im Dashboard template, da dort das Problem in Drafts und Futures wieder auftrat....
Wie ich das für den normalen entry Workflow lösen würde, habe ich mir gerade noch etwas aufgespart... benötigen wird das schon Morgen?

[onli]

Ian, es sieht unsauber aus, das mit Javascript zu machen. Wenn du an der Stelle nicht an den html-Code herankommst bleibt dir aber wohl wenig übrig (aber auch dann: vermeide onclick="...", du hast da ja sowieso jQuery zur Hand, wenn ich das richtig sehe).

Es hat aber auch, glaube ich, nichts mit dem eigentlichen Bug zu tun. Wundert mich aber, dass du nicht in den läufst.

Mein Vorschlag für einen Patch:

Code: Select all

diff -Nur Serendipity/include/functions_config.inc.php /var/www/include/functions_config.inc.php 
--- Serendipity/include/functions_config.inc.php	2011-12-13 19:08:33.607209691 +0100
+++ /var/www/include/functions_config.inc.php	2012-01-12 13:54:20.108011105 +0100
@@ -859,8 +859,12 @@
         return true;
     }
 
-    if (!serendipity_checkFormToken()) {
+    /*if (!serendipity_checkFormToken()) {
         return false;
+    }*/
+
+    if (!serendipity_checkPermission('adminEntries')) {
+        break;
     }
 
     $_SESSION['save_entry']      = $entry;

So geht die Vorschau bei mir wieder. Ich bin mir allerdings nicht sicher, wo serendipity_iframe_create (in der Funktion ist diese Codestelle) noch benutzt wird, und ob checkFormToken() nicht nötig ist.

[Timbalu]

Ob unsauber mit JS oder nicht.... es liegt am fehlenden token, da das preview ja ein link ist und die einschließende form auf POST läuft, bei der der token bereits mitgeliefert wird. In meiner geposteten Lösung ist dieser onclick event natürlich Quatsch, da das Eigentliche der Token ist, den ich in meinem entrylink im Dashboard für draft und futures bereits gesetzt habe.

Vorschlag:

Code: Select all

    if ( !serendipity_checkFormToken() || !serendipity_checkPermission('adminEntries') ) {
        return false;
    }

in der function serendipity_iframe_create(). Zu überlegen ist, ob man das auf die adminEntries beschränkt, denn wie ist das eventuell bei Redakteuren, die ein Draft geschrieben haben und es als preview sehen wollen?

und

Code: Select all

&<?php echo serendipity_setFormToken('url'); ?>

ins GET bei line ~287 in der include/admin/entries.inc

Code: Select all

                            <a target="_blank" href="<?php echo $entry['preview_link']; ?>&<?php echo serendipity_setFormToken('url'); ?>" title="<?php echo PREVIEW . ' #' . $entry['id']; ?>" class="serendipityIconLink"><img src="<?php echo serendipity_getTemplateFile('admin/img/zoom.png'); ?>" alt="<?php echo PREVIEW; ?>" /><?php echo PREVIEW ?></a>

Die Frage wäre dann ja nur noch, ob das irgendwelche Auswirkungen für die von Garvin angedeutete Frontend User Geschichte hat.

[Timbalu]

Ein Problem das ich in dem Zusammenhang noch habe ist, dass der ge-preview-te Inhalt nicht durch nl2br geht. Ist das bei dir auch so?
Das müsste man noch irgendwie reinfummeln für den eigentlichen Entrytext. Im preview_iframe.tpl geht es nicht, da die Ausgabe schon als paket assigned wurde.

[garvinhicking]

Hi!

Den Token-Check müssen wir auf jeden Fall irgendwie drinlassen; er ist ja dafür da, damit niemand eine manipulierte HTML-Seite Seite vorbereitet, die ein HTTP POST zu dem eigenen Blog macht und alle benötigten Variablen setzt um dann eine Vorschau eines gefakten, neuen Blogeintrags vorzubereiten.

Die Technik ist diese, dass jemand ein HTML FORM vorbereitet dass so aussieht wie das, was s9y zum Artikel schreiben benutzt. Das Formular wird auf der manipulierten Seite aber versteckt, und mit "bösem" HTML-Inhalt befüllt. Wenn der User die böse Seite betritt wird er zu seinem Blog geleitet, dort wird ohne sein Wissen das HTML FORM geparst und ihm eine Vorschau des ihm unbekannten Blogeintrags präsentiert, und böser javascript-Code ausgeführt.

Dies wird durch einen Token verhindert, denn den kann eine fremde Seite nicht faken.

Wenn wir das nun umgehen muss sichergestellt werden, dass dann ausschließlich ein bestehender Blog-Eintrag previewed wird (solange adminEntries besteht!) und in diesem Preview kein manipulierter $serendipity['POST']['entryBody'] (oder wie sie heißt) verwendet wird.

Grüße,
Garvin

[Timbalu]

Die Welt ist ja so schlecht...!

Und was ist mit meiner Lösung?

Das nl2br parsing könnte man ja durch einen weiter Parameter i.e. &serendipity[parseNL]=true mitgeben der dann das nl2br plugin dort auslöst wo das ganze zusammengestellt wird. (wo ist das?)

[garvinhicking]

Hi!

Ah, deine setFormToken-Lösung habe ich übersehen. Die klingt eigentlich vielversprechend; wenn das klappt, dann würde ich damit keine Probleme sehen?

nl2br parsing verstehe ich jetzt nicht richtig, wozu sollte das angewendet werden? Das Preview sollte eigentlich immer alle markup plugins anwenden (sonst ist ein preview ja witzlos).

Grßüe,
Garvin

[Timbalu]

Hi Garvin

Fakt ist, hier hab ich einen Testeintrag mit ein paar Newlines erstellt, nur ein paar Sätze mit fettem Beginn, der als Draft gespeichert und mit dem Link-Preview (also aus der Entries-Übersicht heraus) mit nl statt br im admin_iframe.tpl ausgegeben wird. BBC etc wird richtig geparst.

Vielleicht habe ich ja auf meinen Testsystem irgendwo was falsch eingestellt, wüßte aber nicht wo. Deswegen bat ich das mit den genannten Einstellungen mal anderswo zu testen.

Mich mutet das aber eher so an: Wahrscheinlich gibt es irgendwo, bevor das ganze für {$preview} assigned wird, ein if isset("kommt von input...?") vor der Weitergabe an das nl2br plugin, denn dieser gespeicherte Draft-Eintrag wird dann korrekt ge-preview-ed, wenn ich im Bearbeitungsmodus bin und auf den input type button preview drücke (gleicher Vorgang, gleiche Ausgaberoutine, richtiges Ergebnis). Bevor ich mich da lange suchend abquäle, weißt du wahrscheinlich eher und schneller wo das sein könnte...

[garvinhicking]

Hi!

Du sprichst vom nl2br plugin das nicht klappt? Hast Du es evtl mal mit dem nl2br von z.b. s9y 1.5 probiert? Möglicherweise sind die zuletzt im nl2br plugin vorgenommenen änderungen das problem?

Grüße,
Garvin

[Timbalu]

Nee, das hatte ich vorher auch schon mal in Augenschein genommen und jetzt sicherheitshalber auch noch mal das serendipity_event_nl2br.php file ausgetauscht (jedenfalls mit dem aus der 1.6 version).

Nochmal:

• draft preview mit input button aus entry bearbeiten geht
• draft preview als link (inkl. token) aus entries übersicht wird nicht nl2br geparst.

Ich wäre ja schon weiter, wenn ich definitiv wüßte, dass das bei jemand anderen mit diesen Einstellungen geht.

[Timbalu]

Garvin, ich habe mir heute Morgen mal die Mühe gemacht das zu verfolgen.... und habe mich dabei auf die Ausgaberoutine konzentriert.

Am Ende kam ich aber zur Erkenntnis, dass ep_cache_body und somit wahrscheinlich auch ep_cache_extended im Falle eines Drafts (und nur DRAFT!) nl2br-ungeparst gespeichert werden.

Jetzt muss nur noch das Wo und Warum gefunden werden, die verhindern, dass Drafts beim Speichern im Falle von entryproperties und cache nl2br-ungeparst bleiben! Das kann doch nicht nur bei mir so sein.... Shortcut Ideen dazu?

Im Gegensatz zur input button Vorschau, wird natürlich bei einem direkten Link das ganze aus dem ep_cache_x generiert, wenn als solches vorhanden...

[garvinhicking]

Hi!

Evtl wird nur frontend_publish statt auch frontend_save (oder so) bei nl2br abgefragt? Man könnte die hooks mal mit denen von z.b. bbcode vergleichen?

Grüße,
Garvin

[onli]

Funktioniert jetzt die Vorschau, ist der patch im code?

[Timbalu]

Ja

https://github.com/s9y/Serendipity/comm ... 266299afb3

Wie im Note angemerkt noch ohne die checkPerm... ein test wäre daher gut!