Hi, i'm back from vacation and parental leave right after. Sorry for the delay ;-)

@OMoskalenko Just an interim report. I'm working on a solution, but due to beeing really busy lately and my upcoming holiday, it will take more time (some weeks). In the meanwhile if you are in urgent need of a solution, you can take this prerelease branch of my private github repository: github.com:enst80:mediawiki-extensions-Auth_remoteuser:T200451 . It represents an early state, but should be usable. It accepts session cookies, when the new configuration option $wgAuthRemoteuserTrustSessionCookie = true; is set (and deletes the cookie if set to false an no remote user name validates this cookie).

If $_SERVER['REMOTE_USER_DATA'] is not set, then Auth_remoteuser won't do anything, even if there are cookies present with valid session and user information.

New version 2.1.0 released and tagged accordingly in gerrit.

@Salehtahini
If the problem still persists, you can reopen this task. I'll mark it as resolved for now.

Oh yes! The funny thing is, i had issues with using Visual Editor and wanted to solve these first. But thanks to T198928 the issues are are gone ^^ Now i'm fine with releasing a 2.1.0 version ;-)

Yes, indeed! I'll upload the backported patches.

Thanks @Revansx for your detailed description and thanks @Tgr for the hints in the right direction. Yes, Auth_remoteuser doesn't handle the creation of new empty sessions correctly.

Please can you test, if this patch solves your problem? I think it is related to the other bug report T198928 (like @Revansx mentioned already).

Backporting done.

@jrchamp : Tried it with your suggestion of using a $disable value, but that looked more complicated than the current patch set and its use of the array_push() function.

Task closed before 1 year passed. Celebrate! :-)

Because this is a severe bug, which inhibits the extension usage on bigger MW installations, i'll backport the patch to all affected branches.

Finally ;-)

Thank you all. New version 2.0.1 released (annotated tag also).

Answering my own question :-)

Btw, we don't have to comply with the semantic versioning scheme, it's just a recommendation, not a must. We even do not follow it right now, because there are patches already (T167615 and T185377) which did not raised the patch number of our version string. We are still at 2.0.0. ;-)

BTW, backporting to LTS branch REL1_27 is not necessary, because the MediaWiki core commit c6569e7dc70ac07db5d86e429d7f3d0d42792915 with it's specific line (which causes this bug in our extension) was committed after REL1_27 was branched off from MW core master.

Cherry-picked to all affected branches from REL1_28 to REL1_30.

Patch prepared. Will upload it for review soon. (See branch T185377 on my github page for early access ^^)

After nearly a year there seems to be all important information regarding the "new" version was added to the according documentation page. Therefore we can close this task.

Took me a while to get behind the problem. No, not nearly a year ;-) Sorry for beeing that late to this task.

Thank you for your detailed description.

Hi again,

Hi all,

Hi,
i'm all for backporting to these two branches, because:

1. Both branches pointing to a commit which doesn't work with the related MediaWiki 1.27 or 1.28 versions.
2. MediWiki extension ExtensionDistributor (or its according page Special:ExtensionDistributor) selects tarballs by branch name, which do not give a working version (because of 1).
3. There's no extra work for backporting to REL1_28 because it would be a simple fast-forward-merge.
4. There's little work for backporting to REL1_27 because this branch is one commit off from the according master branch commit and it touches the .gitreview file only, which isn't changed by the current commit for v2.0.0. So the (backport/cherry-pick) merge should be simple.
5. Especially MediaWiki 1.27 is supposed to be LTS (long term support). An extension should follow this if applicable.

Phew, long time for an update ;-) But here it is: latest PatchSet - Ready to be released (after review and bugfixing)

Okay, that was a rather big overhaul of a single PatchSet. I still have some points i wanted to be in before release (merge). But on the other hand i want your feedback of the things which are in already. So i uploaded the current state of my rework (PatchSet 12). So lot's of stuff to review for you at least. ;-)

Thanks @GICodeWarrior for valueable feedback. I am busy this week, but didn't had the time to finish the implementation of your worthwhile remarks. I'll upload a new Patch Set next week.

Thank you @GICodeWarrior for responding to my email and @jrchamp for still reviewing my current patch fixes.