It was found during T335425 that:
- background processes relating to reading list syncing were receiving 401 errors and automatically logging the user out.
- temporary accounts were not being recognised by the app as being logged in
- app does not attempt to fetch notifications
Tasks
- Update iOS authentication management to support temporary accounts
- Audit app functionality in relation to temporary accounts, testing via test.wikimedia.org
- Engineering only fixes to features to support or at minimum fail gracefully when handling temp account authentication
Engineering Details
- Clone cookies after edit posts
I do not expect our newer networking stack calls (WMFBasicService) to return any responses with the cookie set. As of today those calls are fundraising config calls, Apple Pay payment calls, and fetching the article summary. No MediaWiki editing calls go through here. So WMFData and by extension WMFBasicService can be left untouched.
What that does mean is that we need to make some changes to the legacy networking class in Fetcher.swift. For any POST calls there, in the response completion block we need to call self.session.cloneCentralAuthCookies(), that way any new cookies that spin up from an edit POST are propagated to the other wiki domains.
- (Cleanup) Remove Session.isAuthenticated
Session should not care about "authenticated" states, instead it should only be aware of cookies (if there are valid ones, to clone cookies, or to remove cookies). WMFAuthenticationManager should be the only class that modifies and is aware of an "authenticated" state.
- Add convenience isTemporaryAccount public Boolean property to WMFAuthenticationManager
Check WMFAuthenticationManager's loggedInUsername format and set to true if temporary account username pattern matches.
- Audit related calls throughout the app and consider if action should be taken if isTemporaryAccount = true. If not, wrap up logic in a (if !authenticationManager.isTemporaryAccount) conditional. Maybe reference T361765 for this
getLoggedInUser completions
getLoggedInUserCache calls
loggedInUsername calls
isLoggedIn calls
We should also hash out what we send for analytics. isAnon=?
This is hopefully enough to patch up the underlying bugs.
Additional things to test (Reference T361765 for this):
When in a temporary account state, terminate the app then relaunch. The app attempts to login the user again when relaunched, and it's unclear what will happen here. Do an edit, is the temporary account retained?
Test editing on pilot and non-pilot wikis. We want to be sure any of our cleanup methods (resetLocalUserLoginSettings, session.removeAllCookies()) do not clear out pilot wiki cookies as we edit back and forth.
Next level cleanup:
There are several methods and states that reference a "logged in" user. Upon first glance these appear to be users that fetched the MediaWiki API userinfo API (which returns the authenticated user info). It seems likely temporary accounts will have a valid userinfo response from that API. We should rename these methods to reflect this is nonIP users, perhaps, since now these methods could reference both logged in users AND temporary account users.
Add a very clear enum of state in WMFAuthenticationManager, instead of "isLoggedIn" & "isTemporaryAccount":
WMFAuthenticationManager { enum LoginState { .anonymous .registered //(permanent) .nonregistered //(temporary) } let var loginState: LoginState?
QA Notes
These are the test steps we followed for Development testing:
- Launch app in a logged out state.
- Edit an article on Test Language and publish. After editing, go to revision history and confirm you see the temporary account name.
- Terminate the app. Run again, then edit an article on Test 2 Language and publish. After editing, go to revision history and confirm you see same temporary account name as you did in step 2.
- Now edit something on EN Wikipedia. You can edit your own user talk page if you don't want to edit an article (search User_talk:TSevener (WMF) for example). After editing, go to revision history and confirm you see an IP address as your edit.
- Go back and edit a Test Language article. Go to article history, confirm you see the same temporary account name as you did in step 2.
- Log into the app. Go back to Test, Test 2, and EN Wiki articles (or talk pages) that you edited earlier. Edit them again. Go to article history and confirm you see your username as the edit.
- As you click around the app, note if anything feels like a regression with authentication (unexpected logged out panels, Settings displaying an unexpected logged in our out state, etc.).