I'm writing an iPhone App for iOS 9 and after. One of my goals for this App is that it should be able to send tweets on behalf of my user through the one or more twitter accounts the user owns.
I've integrated the STWitter Library into my App and I've gotten the functionality I want working almost as I'd like. I say 'almost' because a small part of it is not working as I expected and it is this part that I'd like to focus on here.
I might say that I do not think this issue is a STTwitter related issue as another poster, who posted about a similar problem here, was using the Twitteroauth library.
Currently, in the version of my App that I am testing, I have two buttons labeled, "@acct1" and "@acct2".
Each button represents a Twitter account that I own. Both my Twitter accounts use the same password.
If I touch one of the buttons, the App will create and send a tweet to my twitter account associated with that button.
My App is stil in testing mode so currently I store the oauth tokens I receive in non-persistant memory. Therefore, my oauth tokens evaporate if I restart the App. Later, when everything's sorted out, I will store them in User Defaults.
So, the first time I press either the @acct1 or @acct2 button after an App restart, I will not have the required oauth tokens and I will have to initiate a round-trip to Twitter to get them.
On any subsequent reuse of that same button, prior to restarting the App, I will still have the oauth tokens and I won't have to go to Twitter first.
Anyone who has integrated the STTwitter Library and worked though the wonders of OAuth will be familiar with the basic outlines of all this.
That's enough background, I think. Now to the problem:
Assume now that I've just restarted my App. When I touch @acct1, my code determines I am not holding oauth tokens so I begin the sequence to make a round-trip to Twitter to get them.
First I send Twitter a postTokenRequest.
It comes back successfully and its sucess_block contains a URL with various bits of data which I then pass to Safari.
Safari uses the URL to go to the Twitter website and when that website page appears, I am looking a screen entitled, "Authorize to use your account?"
That screen presents me with two text boxes. One for userID (or phone number or E-Mail address) and the other for password. I am only interested in the userID option here.
Here's my question/problem --------------
In the parameters I pass with my postTokenRequest, I can optionally include a value for the 'screen name' parameter.
NOTE that 'Screen Name' and userID are, I believe, interchangeable terms here.
My assumption is that if I include a 'Screen Name' among the passed parameters of my postTokenRequest, then when Safari presents its "Authorize to use your account" screen to my user, the userID field on that screen will be auto-filled with what I passed as 'Screen Name'.
I also assume that if I pass nil for the Screen Name, the userID field presented will be empty and I will be required to fill it in.
Below, are two tables.
Table 1 - this is what I expect to happen:
I Rqst Safari userID
Press Token userID I
case button Sends shows enter
---- ----- ----- ------ ------
1a @acct1 nil nil @acct1
1b @acct2 nil nil @acct2
<App restarted here so saved oauth tokens evaporate>
2a @acct1 acct1 acct1 none
2b @acct2 acct2 acct2 none
Discussion of Table 1:
In case 1a and 1b, when I touch either @acct1 or @acct2, the Screen Name I sent with postRequestToken is nil. In both these cases, I expect Safari's presented userID to be blank as well requiring me to enter it.
In case 2a and 2b, when I touch either @acct1 or @aact2, the Screen Name I sent with postRequestToken contains the correct value of acct1 or acct2. And in both cases, Safari's presented userID is correct and I do not have to do any data entry.
Table 2 - but this is what actually happens:
I Rqst Safari userID
Press Token userID I
case button Sends shows enter
---- ----- ----- ------ ------
1a @acct1 nil nil acct1
1b @acct2 nil acct1 acct2
<App restarted here so saved oauth tokens evaporate>
2a @acct1 acct1 acct1 none
2b @acct2 acct2 acct1 acct2
Discusion of Table 2:
Case 1a works as expected but case 1b does not. In 1b, Safari shows acct1 as the user ID even though the request token sent was nil for Screen Name.
Case 2a works as expected but case 2b does not. Safari shows acct1 as the user ID even though the request token sent acct2 for the screen name.
General discussion:
I think this post was describing this problem as well but the poster didn't get any help.
It looks to me likes there's a problem on the Twitter end with an unintentional persistence of data (Screen Name/userID) from the last successful issuance of oauth tokens. Note in Table 1 that once case 1a is approved, the Screen Name for 1a persists and appears as the Screen Name in 1b's request. The same thing is evident with 2a and 2b.
I note as well that if you wait awhile between requests, the persisted data disappears.
At the beginning of this post, I mentioned that both my Twitter accounts share the same p/w. That makes this persistance problem potentially a big problem for me or for any user of mine who chooses to use the same password for their several Twitter accounts.
If such a user sets up several Twitter accounts in quick succession with my App and fails to notice that Twitter is persisting the Screen Name of the previously approved account as the Screen Name of the currently being requested account, then the new Twitter account will be misdirected.
The problem could be caught if each Twitter account being setup had a different p/w however. In this case, the mismatch between the Screen Name/userID and the p/w would cause a rejection.
I'm not keen on advising my users to use different p/w's for each of their several Twitter accounts. Nor could I enforce it as the entire point of OAuth is that the App should know nothing of the user's p/w.
The best I can see to do so far is to
(1) always send a nil for Screen Name in the postTokenRequest.
(2) inform my users, as they setup a new Twitter accounts on my App, that they should never accept what Twitter preloads in the userID field of the "Authorize to use your account" screen but to always replace anything they find there with the userID that they know is correct.
Any and all comments would be appreciated.
