Au moment du login, plusieurs cookies sont créés dont en particulier :
nc_session_id : il contient le nom du fichier de session créé dans le répertoire /sessions
oc70txxx99xx : le nom de ce cookie correspond à la variable « instanceid » définie dans le fichier config/config.php. Il contient AUSSI le nom du fichier session créé dans le répertoire /sessions
Une fois arrivé sur la première page (typiquement le dashboard)
soit ces cookies ne sont pas modifiés, et là, tout se passe bien, la connexion « tient »
soit environ 1 seconde après l’affichage, le contenu du cookie oc70txxx99xx est modifié par un appel javascript. Dès que cette valeur n’est plus identique à celle d’origine (c’est à dire qu’elle n’est plus égale au nom du fichier de session), le message de déconnexion apparait.
Je n’ai pas réussi à trouver quel JS modifie ce cookie, mais le JS c’est pas ma tasse de thé !
Donc à mon avis, il faut trouver quel appel JS modifie cette variable, et pourquoi (et pourquoi desfois oui, desfois non !)
On va y arriver !
Je devrais pouvoir libérer du temps pour regarder cela ce soir en débuggant ces appels JS, merci pour la piste @jfcavalier1
De mon côté, j’ai l’impression d’avoir une solution de contournement temporaire.
En effet, je parviens à faire un usage admin (et même fichiers etc… mais je n’ai pas trop poussé) en forçant la redirection après le login sur la page « Activités ».
Quelques retours suite à ton message
J’ai essayé en utilisant ?redirect_url=/index.php/apps/activity/
J’ai fait de nombreux essais et malheureusement, j’ai eu la même erreur. Pas sur la page « Activité », mais ensuite, quand j’ai cliqué sur « Fichiers ». Effectivement il m’a semblé que c’était moins systématique, mais difficile à dire, vu que l’erreur survient aléatoirement…
Par contre j’ai fait 2 découvertes, la plus intéressante est la seconde :
en utilisant login?redirect_url=/index.php/apps/activity/ pour une raison inconnue, le cookie nc_session_id n’est plus créé !?! Et le plus bizarre, c’est qu’ensuite, en faisant des logins « normaux » (sans ?redirect_url etc…), il n’est plus créé non plus ! Je veux dire que ce cookie « n’existe plus » ?!? J’ai fait le test sur 2 instances différentes de NextCloud et même phénomène !!! Impossible de faire réapparaitre ce cookie nc_session_id une fois que j’ai utilisé le ?rediretur_url Le pire c’est qu’il me semble que ce n’est même pas à la première utilisation de ?redirect_url que ça se produit, mais à la seconde ou troisième !?! Totalement déconcertant !
mais du coup, ça m’a permis de constater que LE problème vient uniquement du cookie oc70txxx99xx (le nom de l’instance NC dans config.php). C’est ce cookie qui est « instable ». La présence ou l’absence de nc_session_id ne change rien. Ce cookie oc70txxx99xx pour une raison inconnue est parfois modifié (et parfois supprimé, je l’ai constaté au moins une fois) par un appel JS en cours de session, au tout début surtout apparemment, et son contenu n’est plus égal au nom du fichier de session sur le serveur. Et là ça provoque une déconnexion.
Re-
Après quelques tests, juste un petit supplément qui peut être utile pour debugger.
Effectivement, lors de l’utilisation de login?redirect_url=/index.php/apps/activity/
il n’y a jamais de déconnexion sur tant qu’on reste sur l’app Activity
idem apparemment (j’ai moins fait de test) sur l’app « settings ».
quand je passe de l’app « activity » à l’app « files » ou l’app « dashboard » (en cliquant sur l’icone) il y a déconnexion aléatoire (environ 1 fois sur 3 chez moi)
lorsque cette déconnexion se produit, c’est systématiquement au premier appel (de « files » ou « dashboard »)
Ca laisse donc penser que le JS fautif est utilisé par les apps « files » et « dashboard » et pas par les apps « activity » et « settings »…
mettant un 'tempdirectory' => '/var/www/vhosts/xxxxxx/var/tmp/nextcloud', car je voyais des erreurs à ce sujet
désactivant les applications mail, weather et talk (certaines faisaient des exec qui échouaient et apparaissaient dans les logs)
rajoutant d’autres debugs pour mieux comprendre
Et je ne suis pas encore parvenu à voir plus de pistes.
Quelques erreurs dans /logs/error_log que je n’ai pas directement relié au problème semblent toutefois montrer que l’hébergement est sans doute un peu trop sous-dimensionné pour du Nextcloud :
Failed to connect to the database: An exception occurred in driver: SQLSTATE[08004] [1040] Too many connections
Failed to connect to the database: An exception occurred in driver: SQLSTATE[HY000] [2002] Connection refused
No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /var/www/php/xxxxxxx.sock (*) failed
AH01079: failed to make connection to backend: httpd-UDS
Pour l’instant j’ai abandonné de manière à avancer sur la mise en place de Nextcloud pour l’association qui l’attend, et j’ai dû me résigner à l’installer ailleurs. J’espère pouvoir continuer à débugguer l’instance sur ouvaton et y rappatrier à nouveau les gens dessus … sinon tant pis.
Si ça peut aider, j’avais tenté de répondre à la demande d’un développeur à propos du bug en question, mais pour l’instant je ne comprends pas sa dernière réponse. Il a besoin de logs de la console du navigateur quand l’erreur se produit.
Pouvez-vous essayer d’ajouter dans config/config.php de vos Nextcloud la ligne (si vous avez l’application calendrier) :
'defaultapp' => 'calendar',
Puis tester un peu pour voir si le problème de déconnexion se présente toujours ?
Avec cette ligne c’est le calendrier qui sera ouvert après la connexion, et plus le tableau de bord ou les fichiers.
Je viens d’essayer sur un de nos Nextcloud, et sans se connecter par défaut sur l’application ‹ dashbord › ou ‹ files ›, le problème de déconnexion juste après la connexion avec le message « Problème d’actualisation de le page, actualisation dans 5… » ne semble plus se présenter. Je vais essayer de tester à différents moments de la journée pour confirmer.
Bonjour,
Effectivement, j’ai basculé plusieurs fois entre « calendar » et « files » et c’est systématique : aucun problème avec « calendar », quelle que soit la page visitée ensuite, alors qu’avec « files », c’est plusieurs déconnexions/reconnexions avant d’obtenir un fonctionnement stable.
Hubert
pour moi « erreur interne du serveur ». Mais je suis à la ramasse depuis tellement longtemps que je vais tenter une nouvelle installation avant de réajouter cette ligne; je reviens…
Il me faut juste le quartd’heure nécessaire à tout effacer par ftp… (je prépare le web-installer)
[20mn après]
Je viens de
tout effacer (via ftp) dans mon dossier
y renvoyer le dernier setup-nextcloud.php fraîchement retéléchargé
relancer l’installation
accepter l’installation automatique des « applis recommandées »
noter que (comme les fois précédentes) l’install de « Collabora online » échoue (« Échec lors du téléchargement ou de l’installation de l’appli »), les autres se passant bien.
Le symptôme habituel s’est présenté (impossible de recharger cette page, rechargement dans 3, 2, 1…
Suite au nouveau dialogue de login qui apparaît, sans même éditer config.php, j’ai immédiatement cliqué sur l’icône du mail
→ j’aboutis sur une page stable, qui me demande de créer mon email.
A partir de là je navigue sans erreur dans le calendrier (vide), les contacts (vides aussi).
Cliquer sur les photos n’amène pas un re-login mais le message « une erreur est survenue »
Le dashboard (initial) est stable
Les documents plantent comme initialement après une dizaine de secondes, mais pas toujours.
La synchronisation automatique avec un dossier sur ma machine locale (Linux Debian, l’utilitaire fonctionne bien avec d’autres instances NC) génère systématiquement des erreurs « 500 internal error » et ne synchronise rien.
Toute tentative d’upload de doc, y compris par glisser-déposer, génère une erreur « inconnue ».
Je pourrais ajouter cette solution de contournement au signalement du bug github mentionné plus haut. L’avez-vous trouvée vous-même, ou y aurait-il une source à mentionner par la même occasion ?
Moi-même, mais quelques tests supplémentaires montrent que le problème est également présent avec l’application calendar par défaut à l’ouverture d’une session, même s’il semble se présenter moins fréquemment.
