Jump directly:

Forum

papaya Forum

The Forum is no longer actively maintained and only left here for archival purposes.

Back Answer

Jens

Hallo,

 

mich beschleicht ein weiteres Problem: Im backend wird weder die Seitenvorschau (XML/html) noch eine Bildervorschau angezeigt.

Im Frontend ist alles ohne Probleme, alle Bilder werden korrekt angezeigt, ebenso die html Ausgabe.

Ich habe bereits caching und dergleichen ausgestellt und jetzt weiß ich nicht weiter, woran es liegen kann.

Für die Seitenvorschau wird der Fehler 403.2 angezeigt, Access forbidden. Anstatt der Bilder sind nur deren Rahmen ohne Inhalt zu sehen.

Was kann ich da tun?

 

Mit freundlichen Grüßen,

Jens

Jan Zerebecki

Das liegt vermutlich daran, dass die Vorschau die Session nicht mitbekommt.

Es könnte daran liegen, dass das Cookie nicht mitgesendet wird. Oder daran, dass wenn Cookies nicht funktionieren die Session-ID im Pfad weitergereicht wird, aber dann nicht der Vorschau übergeben wird.

Beim Ansehen der Vorschau: Wie lautet die URL, die in der Adresszeile des Browsers im Backend steht? Wie lautet die URL in der Vorschau (z.B. über den Vollbild Button zu finden)?

Jens

Ah...

wie mir scheint liegt das an den Sessions:

WARNING #2 Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/home/.../PHP) in Unknown:0

WARNING #2 Unknown: open(/home/.../PHP/sess_s6csn2grd985c2rg43jc5pfas7, O_RDWR) failed: No such file or directory (2) in Unknown:0

Logfile-Auszug aus Papaya.

 

Die Url im Vorschaufenster (ganzes Fenster) sieht so aus: index.1.de.html.preview?p_date=1276671273

 

Leider bin ich mir Sessions nicht so ganz bewandert... Der session.save_path ist auf das angegebene Verzeichnis gesetzt (Standardeinstellung vom Server, ich habe nur ein paar Ordner rausgenommen)

Weshalb ich diesen Fehler nicht verstehe. Momentan steh ich auf dem Schlauch.

 

MFG Jens

Thomas Weinert

PHP kann die Session-Datei nicht schreiben. Entweder exisitiert das Verzeichnis nicht oder es ist aus anderen Gründen nicht zugreifbar (Rechte).

Gruß

Thomas

 

Jens

Okay, ich hab den session.save_path woanders hingelegt, jetzt funktionieren die anscheinend einwandfrei.

 

Das Problem mit der Vorschau bleibt allerdings.

Die URL für die Vorschau ist weiterhin:

index.1.de.html.preview?p_date=1276671273

 

mh... irgendwie erschließt sich mir der Fehler noch nicht ganz...

 

MFG Jens

Jan Zerebecki

Ist der Rest der URL zwischen Vorschau und Backend gleich? Also die Domain und ein möglicher Pfad?

Jens

Ich schreib einfach mal die URLs rein, die bei der Vorschau zu sehen sind, die Domain ist in beiden Fällen dieselbe.

/papaya/topic.php?tt[cmd]=chg_mode&tt[mode]=5&tt[page_id]=4

Das ist die URL bei Vorschau im Backend.

/index.4.de.html.preview

Und das die URL für die Vorschau im Vollbildmodus.

Jan Zerebecki

Das ist gut.

Ist die Einstellung PAPAYA_DBG_PHP_ERROR auf E_ALL und erscheinen keine Fehler/Notices/Warnungen mehr im papaya-Log?

Was ist der Inhalt des Cookie Headers in der HTTP-Anfrage und des Set-Cookie Headers in der HTTP-Antwort?

Jan Zerebecki

Was ist der Inhalt des Cookie Headers in der HTTP-Anfrage und des Set-Cookie Headers in der HTTP-Antwort?

Von jeweils Backend und Preview.

Jens

Ich finde im Quelltext leider keine Daten dazu und leider habe ich auch keinen Zugriff auf die Cookies auf meinem PC.

Kann man das noch irgendwo anders nachschauen?

Thomas Weinert

In den Einstellungen des Firefox gibt es unter Datenschutz einen Dialog zum Betrachten und Löschen einzelner Cookies.

Im Firebug (Firefox-Erweiterung) kannst du den Request und damit auch die Cookies betrachten. Mit FireCookie (Firebug-Erweiterung) bekommst du sogar einen eigenen Tab dafür.

Gruß

Thomas

Jens

mh... tschuldigung, aber ich finde auch mit Firebug nichts über Cookies im Quellcode...

Jan Zerebecki

Ich meinte in den HTTP-Headern. Diese kann man in Firebug im "Net" Tab ansehen. Beispiel Screenshot auf http://getfirebug.com/network unter "Examine HTTP Headers".

Jens

Ha, ich habs gefunden.

Leider wird irgendwie mein Eintrag mit den kopierten Headern als Spam erkannt. Sollte es diesmal gehen, kommen die Header der Vorschau im Vollbildmodus in der nächsten Nachricht

Antwort Header

HTTP/1.1 403 Forbidden
Date: Thu, 17 Jun 2010 13:28:44 GMT
Server: Apache/2.2.15 (Unix)
X-Powered-By: PHP/5.2.12
P3P: CP="NOI NID ADMa OUR IND UNI COM NAV"
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Generator: papaya CMS
Set-Cookie: sidadmin=tu78kdpm8e9pjfndv2242p8pk1; path=/; HttpOnly
Keep-Alive: timeout=3, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Anfrage Header

GET /index.16.de.xml.preview HTTP/1.1
Host: www.ddi-team.de
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.ddi-team.de/papaya/topic.php
Cookie: __utma=41044215.919583050.1275919881.1276765501.1276774336.20; __utmz=41044215.1276621376.16.7.utmcsr=ddi-shop.de|utmccn=(referral)|utmcmd=referral|utmcct=/; sidadm
Jens

Ahja, super, es klappt :-)

 

Anbei die Header für die Vorschau im Vollbildmodus:

Antwort Header:

HTTP/1.1 403 Forbidden
Date: Thu, 17 Jun 2010 13:41:50 GMT
Server: Apache/2.2.15 (Unix)
X-Powered-By: PHP/5.2.12
P3P: CP="NOI NID ADMa OUR IND UNI COM NAV"
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Generator: papaya CMS
Set-Cookie: sidadmin=tu78kdpm8e9pjfndv2242p8pk1; path=/; HttpOnly
Keep-Alive: timeout=3, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Anfrage Header

GET /index.16.de.xml.preview HTTP/1.1
Host: www.ddi-team.de
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.ddi-team.de/papaya/topic.php
Cookie: __utma=41044215.919583050.1275919881.1276765501.1276774336.20; __utmz=41044215.1276621376.16.7.utmcsr=ddi-shop.de|utmccn=(referral)|utmcmd=referral|utmcct=/; sidadmin=tu78kdpm8e9pjfndv2242p8pk1; __utmc=41044215; sid=rhnc17lqb4bqco1qknu5j6v592


Jan Zerebecki

Das sieht richtig aus und müsste eigentlich Funktionieren.

Soweit ich da nichts übersehe wird der hier zu sehende 403 ausgegeben weil in papaya-lib/system/papaya_page.php von der Funktion validateEditorAccess() der Wert FALSE zurückgegeben wird. Ich kann mir das gerade nicht erklären. Um weiter zu kommen müsste das überprüft und der Grund dafür gefunden werden. Also als erstes: Welchen Wert hat $GLOBALS['PAPAYA_USER']->isValid vor dem return in der besagten Funktion?

Jens

Das return gibt ein False zurück, genau... Ich wollte dabei noch gleich $GLOBALS['PAPAYA_USER'] überprüfen, aber das echo brachte keinen Wert zurück.

 

(Um das zu überprüfen habe ich in der Funktion eine IF Funktion eingebaut (if globals == true echo true))

Kann ich in dem Zusammenhang noch etwas testen? Bringt vielleicht die phpinfo was?

Jan Zerebecki

Bevor wir da weiter machen, noch ein paar Grundlagen, die ich noch nicht erfragt hatte:

Welche version von papaya ist das?

Ist die Einstellung PAPAYA_DBG_PHP_ERROR auf E_ALL und erscheinen keine Fehler/Notices/Warnungen mehr im papaya-Log?

Jens

Hallo,

 

hatte etwas länger hier nicht mehr reingeschaut :-)

 

Also, Version von Papaya müsste 5.0 sein (im März habe ich die aktuelle Version glaube ich heruntergeladen, in der readme steht auch 5.0 :-) )

Und im Log erscheinen keine Fehler mehr, trotzdem Fehler auf E_ALL gesetzt ist...

Ich bin mit meinem Latein am Ende...

Bedienung ansonsten funktioniert tadellos, das ist das Einzige, was nicht funktioniert.

 

MFG Jens

Jan Zerebecki

Es ist vermutlich am effektivsten auf die aktuelle Version (5.1.2) zu upgraden und zu überprüfen, ob das Problem dort immer noch existiert. (Damit wir nicht viel Zeit ins Debuggen investieren, nur um festzustellen, dass es in 5.1 behoben ist.)

Zuletzt geändert:
07/13/2010 19:40
Jens

Also, ich hab die neueste Version installiert/upgedatet.

 

Es bleibt bei dem Problem. Nun allerdings werden beim Inhalt Erstellen die Bilder nicht einmal in Ihrer ursprünglichen Größe angezeigt, sondern als kleine leere Bilder.

Die Vorschau bleibt bei Access Forbidden.

Keine Fehlermeldungen im Protokoll. Was könnte ich noch tun, um eine Diagnose zu ermöglichen?

Jan Zerebecki

Folgendes ist vielleicht ein Versucht wert:

Was wird in einer .html.preview URL vor dem DOCTYPE ausgegeben, wenn in papaya-lib/system/base_auth.php in der Funktion load() vor dem return die Anweisung var_dump($uid, $this->user); einfügt ist?

Jens

Hallo und Entschuldigung für die späte Antwort, ich hatte Urlaub :-)

 

Vor dem Doctype wird nichts weiter angegeben, wenn ich die Anweisung einfüge...

Jan Zerebecki

Zum Glück ist das Medium hier ja asynchron :) .

Was wird in einer .html.preview URL vor dem DOCTYPE ausgegeben, wenn in papaya-lib/system/Papaya/Application.php die Funktion getObject() wie folgt verändert wird? (Fett Markiertes wurde hinzugefügt.):

  public function getObject($identifier, $className = NULL) {
$index = strtolower($identifier);
if (isset($this->_objects[$index]) &&
is_object($this->_objects[$index])) {
if ('administrationuser' === $index) {
var_dump('old', $this->_objects[$index]->isValid);
}

return $this->_objects[$index];
}
if (isset($this->_profiles[$index])) {
$this->_objects[$index] = $this->_profiles[$index]->createObject($this);
} elseif (isset($className)) {
$this->_objects[$index] = new $className();
} else {
trigger_error(
'Unknown profile identifier: '.$identifier,
E_USER_WARNING
);
return NULL;
}
if ('administrationuser' === $index) {
var_dump('new', $this->_objects[$index]->isValid);
}

return $this->_objects[$index];
}
Jens

ähm... die Datei existiert nicht... könnte es vielleicht daran liegen?

Jens

tschuldigung für Doppelpost:

 

Habe mich verguckt, sie existiert. Folgendes wird da ausgegeben:

 

string(3) "new"
bool(false)
Jan Zerebecki

Diese ganze Sache wird immer unerklärlicher... Ich bin mir nicht Sicher ob sich das auf diese Weise klären lässt, aber hier noch ein Versuch etwas Licht in die Sache zu bringen:

Was wird in einer .html.preview URL vor dem eigentlich Dokument ausgegeben (Achtung es werden mehrere DOCTYPEs ausgegeben), wenn papaya-lib/system/base_auth.php wie folgt verändert wird? (Fett Markiertes wurde hinzugefügt bzw. die erste Zeile Verändert.):

  /**
* sub level
* @var integer $subLevel
*/
var $subLevel = 0;

/**
* is valid status
* @var boolean $isValid
*/
private $isValid = NULL;

function __construct() {
echo "create instance\n";
}

function __get($name) {
if ($name === 'isValid') {
echo "read isValid\n";
return $this->isValid;
}
trigger_error("not allowed to get $name", E_USER_NOTICE);
return NULL;
}

function __set($name, $value) {
echo "set $name\n";
if ($name === 'isValid') {
var_dump($value);
}
$this->$name = $value;
}


/**
* users
* @var array $users
*/
var $users = NULL;

Des weiteren, jedes mal wenn $this->isValid = FALSE; oder $this->isValid = TRUE; in der Datei auftaucht dahinter echo "set isValid FALSE\n"; oder entsprechend mit TRUE einfügen.

Jens

Bei den Veränderungen wird das hier ausgegeben:

 

create instance
string(3) "new"
NULL
set baseLink
set isValid FALSE
set isValid FALSE
set _databaseAccessObject

Es war nur ein Doctype vorhanden. Die Änderungen aus dem vorherigen Post habe ich hierbei noch nicht entfernt.

Für mich ist es auch unerklärlich, der Server (von strato, falls das hilft) erfüllt alle Anforderungen von Papaya...
Jan Zerebecki

Das passt nicht mit der Ausgabe aus dem Post vom 11.08.2010 17:34 zusammen (NULL anstatt false, NULL wäre richtig). Also muss diesmal irgendwas anders sein.

Das "set _databaseAccessObject" besagt, dass die Funktion load() aufgerufen wird, was aber nicht zu den Informationen in dem Post vom 10.08.2010 08:53 passt.

Bei mir sieht das folgendermaßen aus, wenn ich nicht angemeldet bin:

create instance
read isValid
set baseLink
set isValid FALSE
set isValid FALSE
set _databaseAccessObject
read isValid

Die Zeilen mit "read" fehlen also, was eigentlich nicht sein kann, wenn der in meinem vorherigen Post abgebildete Ausschnitt wirklich so in der Datei vorhanden ist.

Wenn eine Session fürs Backend autorisiert ist würde es noch weiter gehen. Ohne Anmeldung im Backend ist die Vorschau nicht erlaubt, weshalb ein 403 Fehler das erwartete Verhalten ist.

Ich vermute, dass wir den Fehler auf diese Weise nicht finden werden, zumindest habe ich ausgehend von den vorhandenen Informationen keine Idee mehr. Der Support würde vielleicht bei direktem Zugriff auf den Server etwas machen können.

Zuletzt geändert:
08/16/2010 15:57
Jens

mh... es ist ungewöhnlich... ich bin alles nochmal genau durchgegangen, hab alles nochmal neu hochgeladen. Die Meldungen sind die selben, wie zuvor.

Bevor wir die Seite online nehmen, werden wir einen Plattformwechsel vornehmen bei unserem Provider, dann schau ich mir das nochmal an. Sollte es dann noch immer die Fehler geben, werde ich mich an den Support wenden.

 

Dankeschön für die Hilfe!!!


Back Answer