Hi, i'm back from vacation and parental leave right after. Sorry for the delay ;-)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 23 2020
Oct 12 2018
Aug 7 2018
@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).
Jul 26 2018
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.
Jul 24 2018
New version 2.1.0 released and tagged accordingly in gerrit.
Jul 20 2018
@Salehtahini
If the problem still persists, you can reopen this task. I'll mark it as resolved for now.
Jul 19 2018
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.
Jul 14 2018
Apr 1 2018
Backporting done.
Mar 23 2018
@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.
Mar 19 2018
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.
Mar 17 2018
Mar 16 2018
Finally ;-)
Thank you all. New version 2.0.1 released (annotated tag also).
Mar 10 2018
Feb 25 2018
Answering my own question :-)
Feb 24 2018
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.
Jan 30 2018
Jan 20 2018
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.
May 1 2017
Apr 20 2017
Hi again,
Hi all,
Apr 18 2017
Apr 17 2017
Hi,
i'm all for backporting to these two branches, because:
- Both branches pointing to a commit which doesn't work with the related MediaWiki 1.27 or 1.28 versions.
- MediWiki extension ExtensionDistributor (or its according page Special:ExtensionDistributor) selects tarballs by branch name, which do not give a working version (because of 1).
- There's no extra work for backporting to REL1_28 because it would be a simple fast-forward-merge.
- 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.
- Especially MediaWiki 1.27 is supposed to be LTS (long term support). An extension should follow this if applicable.
Apr 9 2017
Phew, long time for an update ;-) But here it is: latest PatchSet - Ready to be released (after review and bugfixing)
Mar 24 2017
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. ;-)
Mar 17 2017
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.
Mar 7 2017
Thank you @GICodeWarrior for responding to my email and @jrchamp for still reviewing my current patch fixes.