Page MenuHomePhabricator

[BUG] 500 error uploading when user account does not exist locally on commons
Closed, ResolvedPublic3 Estimated Story PointsBUG REPORT

Description

What is the problem?

If you are logged into SVGTranslate with an account that does not exist on Commons, if you upload you get:

500: Internal Server Error

Unable to get CSRF token from: {"error":{"code":"mwoauth-invalid-authorization-invalid-user","info":"The authorization headers in your request are for a user that does not exist here","*":"See https://commons.wikimedia.beta.wmflabs.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."},"servedby":"deployment-mediawiki-09"}

Bug reported by @ifried.

Steps to reproduce problem
  1. Create an account on https://meta.wikimedia.beta.wmflabs.org/wiki/Main_Page
  2. Go to https://tools.wmflabs.org/svgtranslate-test/File:2002_AJ129-orbit_(multilingual).svg (for example) and click "Log in"
  3. Login as the user you created in step 1
  4. Select a translation language and type some translations
  5. Click "Upload to Commons"

Expected behavior: Some kind of user friendly notification that the user needs to login to Commons first in order to be able to upload translations.
Observed behavior: The 500 internal server error above.

Event Timeline

@Prtksxna We would like to inform the users that they need to login to Commons first in order to upload translations to SVG Translate. Any recommendations for how to do this? Thanks!

Couldn't we set the OAuth URL to Commons instead of Meta? That would ensure they an account.

ifried set the point value for this task to 3.Aug 15 2019, 5:35 PM
ifried moved this task from Needs Discussion to Up Next on the Community-Tech board.

@ifried, does this still need any design work?

@Prtksxna -- No, it's no longer needed. Thanks!

The OAuth URL has been switched to Commons (on both staging and prod); is this issue solved?

I tested (by going through the steps outlined in the ticket), and the bug no longer occurs. Instead, the OAuth URL has been switched to Common now, which resolves the issue. I'll close this ticket.

ifried claimed this task.