Page MenuHomePhabricator

SF 3.* with auth_remoteuser: Edit with form not possible
Closed, ResolvedPublic


It creates the following error:

Deine Bearbeitung konnte nicht gespeichert werden, da Sitzungsdaten verloren gegangen sind. 
Bitte versuche es erneut, indem du unter der folgenden Textvorschau nochmals auf „Seite speichern“ klickst. 
Sollte das Problem bestehen bleiben, melde dich ab und danach wieder an.

It works with the version 2.7 of the Semantic Forms but not with any newer version. I always get this error. Could this be related to changed in the way the edit is handled in the extension? At least a comparison of the files (3.0 and 2.7) via github suggests as much.

It should be noted that a notrmal edit is still possible and no error is shown. Furthermore, we looked (on friday) at the variables responsible that would handle the authentication and credentials (noToken etc.) and there is a false with the forms edit and true once a normal edit is being done.

Originally, we ran the 3.1 version, but we have switched back to the 2.7 for now. Yet, we would like to use the latest software version.

My environment:
MediaWiki 1.24.1 (4688972)
PHP 5.4.36-0+deb7u3 (apache2handler)
MySQL 5.5.40-0+wheezy1
Semantic MediaWiki 2.0

Event Timeline

Temptuousinsolence raised the priority of this task from to Needs Triage.
Temptuousinsolence updated the task description. (Show Details)

What is there much to say:

  • Open site that could be edited with a form
  • Edit site with form
  • Add some content to the page
  • Save page
  • Error (see intial post) appears

The normal (ordinary) procedure. The normal editing process (without a form) works with all versions. Problems are only related to SemanticForms 3.*.

It is not clear how the extension auth_remoteuser and SemanticForms work together and what would be the cause of this error. We have tried various versions of the auth_remoteuser extension, but the error persists, while a change in the version of the SF to 2.7 enabled at least the functionality of the editing with forms again. Judging from a code comparison done on github, there appears to have been a change in the way the authentication process is being dealt with.

I am having this problem, too.

I originally reported it on the talk page, but after using git bisect, I see that it was the fix for T53505 that caused the problem.

gerritbot added a subscriber: gerritbot.

Change 189633 had a related patch set uploaded (by tosfos):
Send $_SESSION to FauxRequest to correctly set wpEditToken on form


Change 189633 merged by jenkins-bot:
Send $_SESSION to FauxRequest to correctly set wpEditToken on form

Yaron_Koren claimed this task.
Yaron_Koren added a subscriber: Yaron_Koren.

I'm guessing that the patch fixed this problem.