[PHP/Drupal] Kan geen Sessie maken

[Xerohumoris]

Na veel zoeken en speuren maar besloten hier de vraag te stellen. Ik heb al enige tijd een kleine test Drupal op mijn computer staan. Na de laatste update van PHP kan hij echter geen sessies meer maken. Of beter gezegd afsluiten. Hij kan namelijk wel een sessie maken maar niet wegschrijven.

Ik krijg bij het inloggen in Drupal namelijk de volgende meldingen in de DB. Dit is voor 1 inlog sessie.

code:

Session opend for Admin
Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php5/) in drupal_session_commit() (line 330 of file includes/session.inc)
access denied for page user/1
Warning: session_destroy(): Session object destruction failed in drupal_session_commit() (line 314 of include/session.inc)

Het vervelende is dat phpMyAdmin ook met sessies werkt en wel gewoon goed inlogt. Ik snap dan ook niet dat het voor drupal niet mogelijk is om een sessie te maken. Misschien dat er een fout zit in de code van de drupal code. Daarom hier de functie drupal_session_commit()

PHP:

function drupal_session_commit() {
  global $user, $is_https;

  if (!drupal_save_session()) {
    // We don't have anything to do if we are not allowed to save the session.
    return;
  }

  if (empty($user->uid) && empty($_SESSION)) {
    // There is no session data to store, destroy the session if it was
    // previously started.
    if (drupal_session_started()) {
      session_destroy();
    }
  }
  else {
    // There is session data to store. Start the session if it is not already
    // started.
    if (!drupal_session_started()) {
      drupal_session_start();
      if ($is_https && variable_get('https', FALSE)) {
        $insecure_session_name = substr(session_name(), 1);
        $params = session_get_cookie_params();
        $expire = $params['lifetime'] ? REQUEST_TIME + $params['lifetime'] : 0;
        setcookie($insecure_session_name, $_COOKIE[$insecure_session_name], $expire, $params['path'], $params['domain'], FALSE, $params['httponly']);
      }
    }
    // Write the session data.
    session_write_close();
  }
}

Hoop dat jullie kunnen helpen ik weet het namelijk niet meer. Alles oplossingen online werken niet. De map waar de sessie in wordt geschreven is namelijk 777 en andere programmas waar onder phpMyAdmin kunnen wel sessies beheren.

Daniël

[MueR]

Het pad /var/lib/php5 is vast niet toegankelijk voor je, as it should be. Je php configuratie klopt niet. Sessions wil je in /tmp opslaan, of in een map ergens bij je site. Niet in /var/lib/php5

[Xerohumoris]

Zoals ik al had beschreven is dat niet het probleem. De sessie van andere scripts waaronder phpMyAdmin worden wel aangemaakt. Ook als ik ze eerst helemaal verwijder. Met de rechten van de map is dus helemaal niets mis. Dit was het eerste waar ik naar heb gekeken.

En ja ik heb hem ook op /tmp gehad. Ik blijf het probleem houden. Ik heb zelfs apache opnieuw gestart en de computer. Maar dit alles mocht niet baten.

Het probleem is dus dat session_write_close() niet kan schreven lijkt het wel. Als er niets is geschreven kun je niets opvragen en ook niet verwijderen. (zie de laatste foutmelding).

Als ik de browser zo instel dat ik toestemming moet geven voor alle cookies (en de ook de inhoud kan zien). Wordt er gewoon een session cookie aangeboden en geplaatst. Drupal verwijst je echter door naar een nieuwe pagina en vraagt daar de inhoud van de sessie op. Deze bestaat dus niet ($user->uid && $_SESSION). Wat dus vervolgens de sessie zal vernietigen (drupal_session_started() is namelijk waar kan de sessie namelijk gewoon openen). Er is alleen niets om te vernietigen. de bestanden bestaan namelijk niet.

Ik heb met een kunstgreep voor elkaar gekregen dat de pagina na het inloggen niet herladen wordt. (ontstaat alleen de eerste foutmelding) Dan staat er in de session map ook geen nieuwe sessies.

Eerst de sessie van phpMyAdmin verwijderen en het op nieuw proberen heeft ook geen zin. Voor het inloggen op de phpMyAdmin wordt een nieuwe sessie gemaakt inclusief bestanden.

extra info:
PHP versie 5.4.15
Apache 2.2.22
Linux 3.4.33-2.24

[orf]

Het lijkt erop dat Drupal de standaard session.savepath overschrijft. (waarschijnlijk een ini_set of session_save_path())

[Xerohumoris]

Dat dacht ik eerst ook. Dit lijkt echter niet het geval. Heb alles wat met sessies in drupal te maken heeft afgezocht... Maar geen geluk.

Drupal past wel een aantal zaken aan met de ini_set maar niet de path. Dit heb ik ook gecontroleerd met phpinfo(). Daar staat bij session.path nog steeds de juiste map. De andere instellingen die met ini_set worden aangepast zijn wel veranderd in het overzicht.

Probleem zit in de versie van php een downgrade lost de problemen af.

[ Voor 9% gewijzigd door Xerohumoris op 14-05-2013 23:13 . Reden: Opgelost (soort van) ]

[Saven]

lijkt me toch eerder een configuratiefout dat een php fout?

[MueR]

Is ook een configuratiefout, maar als TS dat niet wil horen..

[Xerohumoris]

Het zal best een config fout zijn door de map voor de sessie niet op /tmp te zetten.

Zoals ik al had verteld maakte het GEEN zak uit welke map ik liet gebruiken. Ik heb de config namelijk op /tmp gehad gaf 99% het zelfde probleem. Alleen met de melding dat /tmp niet schrijfbaar was. Als ik Apache een map liet kiezen had ik het zelfde probleem wederom.

En voor de duidelijk dit is een bug in de laatste versie(s) van PHP. Die kan namelijk geen sessie wegschrijven met session_write_close();. Alle andere sessies werken wel goed.

Hoe kan het anders dat het downgraden van php (met behoud van configuratie) geen problemen geeft? En als je goed zoekt blijkt dat meer mensen die php >5.4.10 gebruiken het zelfde probleem hebben.

Even over waarom bij mij de sessie map in /var/lib/php5 staat. Dit is geen keuze van mij geweest. Dit is hoe PHP automatisch op openSUSE wordt geïnstalleerd. Daarnaast is het in mijn geval niet slim op te schrijven naar /tmp. Mijn /tmp map is namelijk mijn ram geheugen en niet een deel op de schijf. Ik had namelijk het probleem dat veel tijdelijke bestanden niet werden verwijderd ook niet na een herstart. Met het gevolg dat ik regelmatig een /tmp van meer dan 5GB had. (waarvan hooguit 500kb aan php sessies)