Imported as https://codein.withgoogle.com/dashboard/tasks/5928597153906688/ -- but I do not need it published yet

If I'm not mistaken, this would be a reasonable GCI task. I would be willing to mentor.

@FilipGCI It is preferred if you wait until you can claim the corresponding GCI task before claiming the task here.

I'll mentor this as a beginner task in Google-Code-In-2016. https://codein.withgoogle.com/dashboard/tasks/6396571428061184/

I'd be willing to mentor this as well.

I will mentor this in Google Code-In 2016.

I'd love to mentor this year! Tomorrow I will find a few good first task tasks I'd like to mentor and I'll add myself to the wiki.

In T149100#2758286, @Aklapper wrote:

In T149100#2743036, @srishakatux wrote:

• Improve the design of the page, add GCI logos, make it a bit fancier, to catch kids attention :), etc.?

I've added the logo.
I also looked at Google's GCI blog posts and one includes a photo of GCI 2015 Grand Prize winners but I do not know its license (TODO).

@Mrjohncummings It was never merged. Awaiting code review in Gerrit.

@Mrjohncummings Sorry this has taken longer than I originally intended! I'll be uploading a patch in just a few minutes. I am implementing what you had mentioned with the link test saying "Link", but I wonder if it would be better to use the article title instead.

I can work on this in the next few days.

I'll do this

Can't this be accomplished using the APIQueryAfterExecute hook?

This is working correctly on the beta cluster

As previously mentioned, this change needs to be tested on the WMF cluster in case non-standard headers are filtered out.

Has something changed? The google search linked in the task description no longer seems to show extraneous entries.

I'm going to do this.

So what do I need to do next, now that theres a working patch?

@Tgr: Sorry I didn't have much time to work on this task today. I submitted a small patch for vagrant but I'm having some trouble adding a check to see if the requested database actually exists (ie. is in $wgLocalDatabases). I'm trying to add a check into Maintenance.php or doMaintenance.php, but I can't find a place to put the check after $wgLocalDatabases is actually populated. (At what point is $wgLocalDatabases expected to be populated? I assume they should be available after LocalSettings are loaded?)

I'd like to work on this next. (Nemo told me I could claim it here to 'book' it :P)

Added in https://gerrit.wikimedia.org/r/#/c/254379/

In T122056#1937457, @Anomie wrote:

The patch no longer applies since SessionManager was merged. In making and testing a replacement, I noticed that ApiLogin isn't resetting the session ID at all (because LoginForm does it in processLogin() rather than authenticateUserData()), so I fixed that too.

This patch is based on top of https://gerrit.wikimedia.org/r/264309, which lets us reset all CSRF tokens instead of just the edit token.

[OBSOLETE] SECURITY: Reset tokens on login/logout, and reset session on logout and API login.patch1 KBDownload

I'm working on some if not all of this task for GCI under the mentorship of @Tgr. (Should this task be on the Google-Code-In-2015 project, since it's already imported and published? However, it is a multi-part task.)

Just subscribing in case @Pranavmk98 decides not to claim this, as I'd be interested in this one too.

@Tgr: There wasn't any red I don't believe. If it was trying to run the updates on the main wiki instead of the commonswiki it would pretend to succeed anyway, as it did in T122868 (silently fallback to default wiki)

Use mwscript!

This might be blocked by T122868.

yay :)

:)

yay

I claimed this on GCI.

Claimed this on GCI.

In T122439#1905691, @Tgr wrote:

In T122439#1905578, @Unicornisaurous wrote:

This is really a core mediawiki bug, right? The change needs to be made to core API files.

Some of it, but the imageinfo API mostly just fetches data from File objects, so the substantial part of the change would have to happen there.

This is really a core mediawiki bug, right? The change needs to be made to core API files.

Claimed on GCI...it was a little easier than I expected...

Since the blocking task was completed, could this task get published @Aklapper? Thanks.

Looks like jenkins was playing tricks on me, as an even-numbered build machine has also failed the same way. I suspect increasing the timeout will help as in the patch linked here. (The patch isn't actually mine...gerritbot just thinks it was because I added this bug to its commit message)

Whoops, forgot to claim this here.

I'm going to try to do this using a --rootpage parameter as opposed to an arbitrary prefix parameter, as you suggested in the previous changeset which this was attempted:

This needs to be removed from the GCI website as this task is closed.

This should be removed from the GCI site since its fixed.

I have claimed this on the GCI website.

In T122056#1896233, @Anomie wrote:

In T122056#1896156, @Unicornisaurous wrote:

Here's a simple patch which, from my initial tests, seems to fix the problem. It just sets the wsEditToken session data to an empty string on logout

You fetched a token, logged out, then logged back in and saw the first token didn't work anymore. But try fetching a second token, then logging out a second time and logging back in.

Then delete your session entirely, log in, log out, log back in, and try that second token I had you fetch again.

Here's a simple patch which, from my initial tests, seems to fix the problem. It just sets the wsEditToken session data to an empty string on logout (similar to how wsUserID is set to 0). I don't know if this is the only session data that needs to be reset, or whether setting this on logout is the best place to put this.

In T122056#1895215, @Anomie wrote:

In T122056#1895108, @Unicornisaurous wrote:

This issue has confused me greatly - what good are tokens if the session cookie is whats's being looked at anyways in terms of identifying the user?

The point of the tokens is to prevent cross-site request forgery. You can read the linked article for details, but in short: If we only look at the session cookie, some evil third-party site could embed JavaScript to delete pages and take other admin actions via the API in their page, and then somehow trick wiki admins to visit that page. The CSRF token mechanism prevents that by requiring that the posted request data include the token which the evil third-party site has no way to obtain.

The secret value that's involved in constructing the token is stored in the user's session, since that's an easy and performant way of storing an arbitrary secret value. We could fix this specific bug by just adding the user name to the data used to construct the token, but I suspect we'll prefer to actually change the token secret when the new session is constructed.

This issue has confused me greatly - what good are tokens if the session cookie is whats's being looked at anyways in terms of identifying the user?

I've claimed this on the GCI website.

I claimed this on GCI.

I've claimed this on GCI.

I have claimed this on the GCI site.