Page MenuHomePhabricator

App says I'm logged in, but edits are saved from IP
Closed, ResolvedPublic

Description

I have made two edits with the mobile app (the stable one, not the Beta one), and both edits [1][2] were saved from the IP I was using, even though I am logged in to the app.

[1] https://no.wikipedia.org/w/index.php?title=Petter_Varner&diff=prev&oldid=13500624
[2] https://da.wikipedia.org/w/index.php?title=Christian_Cloos&diff=prev&oldid=7841815

(Also, quite unrelated, but where can I find the localisation for the preset edit summaries, like "Fixed typo"?)

Suggestion (see comment): Use assert=user if the app thinks the user is logged in. The API will then reject the edit if you're not actually logged in.


Version: Stable
Severity: normal

Details

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

The translations are edited in translatewiki.net (TWN). Here is a link to one language.[1] You can change the language with the link after "Translate to" in the upper right.
More info about TWN is in [2]. You can sign up on the main page[3] to become a translator.

[1] https://translatewiki.net/w/i.php?title=Special:Translate&group=out-wikimedia-mobile-wikipedia-android-strings&language=nb&filter=&action=translate&optional=1
[2] https://translatewiki.net/wiki/Translating:WikimediaMobile
[3] https://translatewiki.net

The translations are edited in translatewiki.net (TWN). Here is a link to one language.[1] You can change the language with the link after "Translate to" in the upper right.
More info about TWN is in [2]. You can sign up on the main page[3] to become a translator.

[1] https://translatewiki.net/w/i.php?title=Special:Translate&group=out-wikimedia-mobile-wikipedia-android-strings&language=nb&filter=&action=translate&optional=1
[2] https://translatewiki.net/wiki/Translating:WikimediaMobile
[3] https://translatewiki.net

Yeah, I'm aware of where they are translated, the problem is just that the messages have been translated since at least last July, but still haven't appeared in the app.

Also, the problem described in this bug (being logged in but editing from IP) still persists, I just tested: https://no.wikipedia.org/w/index.php?title=Det_kinesiske_tributtsystemet&diff=13735712&oldid=13733629

Correction: I hadn't tried the number one solution, which is logging out and logging back in (The IT Crowd is never wrong!), so here it worked as normal: https://no.wikipedia.org/w/index.php?title=Det_kinesiske_tributtsystemet&diff=13735718&oldid=13735713

However, the problem of the app showing me as logged in when I'm not really is still something that should be looked into.

Yes, I suspect the edit token expired after a while. I agree that this definitely should be looked at.

Regarding translations: I'm attaching a screenshot

nb_translations.png (1×768 px, 80 KB)
of the production app that was release in January, and it has norsk bokmål translations. We do TWN syncs once a week. Which translation are you talking about? So, if there is something missing please let me know which language/ which string is missing.

Which translation are you talking about? So, if there is something missing please let me know which language/ which string is missing.

Yeah, those in the screenshot look right to me too. The only things I've seen that aren't translated are the pre-set edit summaries ("Fixed typo", "Fixed grammar", "Added links" and "Other"). Everything else looks fine. :-)

I still run into this. Accidentally not saving your edits under your own account is a pretty significant bug.

Ragesoss changed Security from None to Other confidential issue.Mar 24 2015, 4:58 AM
Restricted Application changed the visibility from "Public (No Login Required)" to "Custom Policy". · View Herald TranscriptMar 24 2015, 4:58 AM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript
Restricted Application added a project: WMF-NDA. · View Herald Transcript

One approach is to use https://www.mediawiki.org/wiki/API:Assert . If the app thinks it's logged in (I don't recall if anonymous editing is currently supported), use assert=user .

The API will then fail the edit if the user is not logged in. You can then attempt to re-log them in if you still have the credentials, and re-prompt if the credentials are no longer valid.

Mattflaschen-WMF removed a project: WMF-NDA.
Mattflaschen-WMF changed Security from Other confidential issue to None.

Have discussed with @Ragesoss, marking this as private was an accident. There's nothing exploitable here.

Krenair changed the visibility from "Custom Policy" to "Public (No Login Required)".Mar 24 2015, 9:08 PM
Krenair changed the edit policy from "Custom Policy" to "All Users".

Hi All - It would be great if we could prioritize this bug a little more. It has privacy and Creative Commons licensing implications. Please ping me if you would like to discuss further.

Deskana changed the task status from Open to Stalled.Mar 24 2015, 11:05 PM

Hi All - It would be great if we could prioritize this bug a little more. It has privacy and Creative Commons licensing implications. Please ping me if you would like to discuss further.

This actually has nothing to do with prioritisation. We've still got no way of reproducing this. That means we have no idea how to fix this problem, because we don't even know what the problem is. That hasn't changed.

Thanks to @Mattflaschen for the tip. I wasn't aware that this functionality existed. But really I'd like to fix the underlying problem (whatever it is) rather than put a stupid hack into a single client that uses the API for authentication.

I'm marking this as stalled until someone can provide reproduction steps. Even just a vague idea would help.

@bd808 will see if someone more familiar with the edit API can help us debug this. It may be that we're doing something stupid and we're just not aware of it.

Add assert=user to edit requests from users who are supposed to be logged in? That would fail the edit, but at least not make it not logged in silently. And if you add handling for assertion fails, you can at least have some debugging information.

Add assert=user to edit requests from users who are supposed to be logged in? That would fail the edit, but at least not make it not logged in silently. And if you add handling for assertion fails, you can at least have some debugging information.

I would rather fix the actual problem so that users do not have to sign in again. We can use assert=user if we can't do that.

My guess is that people are logging out on desktop and that the app is not noticing the session is now invalid. Easiest thing to do, which the app should do regardless, is pass assert=user; it's designed for this exact purpose.

You can also check if the token you're getting back is equal to "+\", which means you're logged out. Or you can make a request like https://en.wikipedia.org/w/api.php?action=query&meta=tokens|userinfo to explicitly see who the server thinks you are.

Krenair changed the task status from Stalled to Open.Mar 25 2015, 12:41 AM

I just reproduced the issue by doing exactly what @Legoktm suggested. Logged in on both devices, went to edit a page on the app, logged out on the desktop site, and saved the edit. Edit saved as an anonymous user, despite the app thinking I'm logged in.

Anomie added a subscriber: Anomie.

I would rather fix the actual problem so that users do not have to sign in again. We can use assert=user if we can't do that.

Setting assert=user is a good idea even if you do fix the cause of the logging out, since it will prevent accidental IP edits next time something happens too.

I can probably spare a few cycles on this during our unstructured sprint.

Sounds like this has enough definition for us to move on it now. Thanks everyone!

Can't reproduce :(
Here are the exact steps I'm taking:

  1. Log in within the app
  2. Log in on desktop
  3. Go to a page in the app
  4. Log out on desktop
  5. Edit the page in the app
  6. Save the edit

(I've also tried interchanging steps 4 and 5)

When the API request is made to save the edit, the server returns a "badtoken" error, which the app correctly handles by re-logging-in the user behind the scenes, then resubmitting the edit. The "badtoken" response is given regardless of whether I specify "assert=user".

@Legoktm @Krenair Is there another way I can test this behavior?

Are you testing in the production environment? Maybe it has something to do with CentralAuth?

I have a patch that implements assert=user, but it's still only theoretical, since I can't reproduce the issue myself:

https://gerrit.wikimedia.org/r/200567

Perhaps @Krenair or someone else with an Android device can check out the patch and try reproducing? (I can send an APK if necessary)

@Mattflaschen yep, production environment.

I think an important step is missing:

  1. Wait for x hours/days. Not sure how long, but it'll take some time for the cookie to expire.

Never mind. Got your updates after I wrote my comment.

I tested my instructions again on 2.0-beta-2015-03-23. It definitely results in a logged out edit, and the app still thinks I'm logged in. Your #4 and #5 are the wrong way around @Dbrant.

I checked it with 2.0-alpha-2015-04-02.

My steps:

  1. I logged to the apps with my credentials.
  2. I did some editing - and saved them.
  3. I logged in to desktop - and looked at the 'View history'

Screen_Shot_2015-04-13_at_1.49.35_PM.png (427×899 px, 80 KB)

I checked, just in case, my edits made from desktop are saved with my login.

@Etonkovidova Good. I see it used the IP address. That means you can repro the issue with an apk from the master branch. Would you try to edit with the apk I sent you via email earlier?

Re-checked with 2.0-alpha-2015-04-13 - all edits are attributed to a logged in user.

Screen_Shot_2015-04-13_at_4.27.28_PM.png (489×1 px, 100 KB)

I will check again tomorrow morning - to check the case of possible lost of user session data (as e.g. in VE).

Elena checked with the APK that I sent her, which had @Dbrant's patch in it. So I guess that fixes the problem.

Re-checked next day after the first edit.

All edits were saved with my user name and 'Tags: Mobile app edit, Mobile edit'.

Change 200567 had a related patch set uploaded (by BearND):
Avoid IP edits when user is logged

https://gerrit.wikimedia.org/r/200567

Change 200567 merged by jenkins-bot:
Avoid IP edits when user is logged in

https://gerrit.wikimedia.org/r/200567

Reopening since it's probably not fixed on iOS yet.

@bearND, @Dbrant: In which version the patch for the android version will be released, already in 2015-04-23 or in the next release (btw. when is it?)? :)

@Florian The patch is included in the current production version (2015-04-23). Please let us know if you see this behavior again.

@Florian The patch is included in the current production version (2015-04-23). Please let us know if you see this behavior again.

Thanks for the info. One german user[1] reports this problem, but uses 2015-03-23 (that's why i'm asking here, so i can ask him, if he can update). I will report, if the problem is solved or not :)

[1] https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=8329218

@Fjalapeno why was the iOS project removed from this bug?

Ohoh, see https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketID=8407663 (it's in german).

I fact: The user added an answer to his own talk page and ~~~~ (to create the user's signature) wasn't resolved to the username, but to his actual IP adress :/

Version: Android App 2.0.102-r-2015-05-14