Take the 2-minute tour ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.

Just in the process of final testing for an iPad SE browser, and uncovered some odd behaviour.

I'm using Google for authentication. If I deploy a clean version of the app, and authenticate, I get the "Select OpenID provider" screen, with the usual choices -- SE, Google, Facebook and Yahoo. If I enter my credentials, and the app hasn't been authorised, I get the Approve/Reject screen. If I select Approve, the authentication flow completes successfully and I get my token.

But I want to implement a feature by which the current user can log out, and a different user can log in and view their account. If I de-authenticate and invalidate the token, the next time I try to log in again, the "Select OpenID provider" screen appears briefly, but without the four buttons. Then, the page redirects to the Approve/Reject screen, leaving the user without the chance to enter a different set of credentials.

I've cleared the cache and cookies as best I can, so I figured there's the possibility that some kind of caching might be something server-side. As evidence to the contrary, however, if I blow away the app and re-deploy, I get the "select provider" screen again.

Has anyone seen this kind of behaviour, though? Is it expected?

EDIT: Could it be HTML5 Local Storage? The saved credentials seem to persist even through a reboot. Is anyone aware of how Google caches credentials?

Possibly also related to this post.

share|improve this question

2 Answers 2

This is how I managed to completely log out the user, I'm not sure about the URL I use, it's not documented by the SE API, but it's the one users get sent to when logging out on the website themselves. But I think it maybe that by loading a page into a UIWebView it saves the cookie storage (as empty), so you could try loading any page and see if that still works.

-(void)logout {
    [[[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies] enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
        [[NSHTTPCookieStorage sharedHTTPCookieStorage] deleteCookie:obj];
    }];
    UIWebView *webView = [[UIWebView alloc] init];
    [webView setDelegate:self];
    [webView loadURL:@"https://stackauth.com/auth/global/clear-session"];
    self.logoutWebView = webView;
    [webView release];
}

-(void)webViewDidFinishLoad:(UIWebView *)webView {
    [webView stringByEvaluatingJavaScriptFromString:@"localStorage.clear();"];
    //update UI etc
}
share|improve this answer

Invalidate an access token doesn't log the user out of the sites themselves.

What you're seeing here is the user's global auth session kicking in. To completely log someone out of the Stack Exchange network (other than having them actually use the "logout" link), you need to clear cookies and local storage.

share|improve this answer
    
Thanks, Kevin. Unfortunately iOS support for managing Local Storage is fairly poor, and very poorly documented. Is there any other mechanism at all for doing this? While messing about with cookies, I noticed that if I immediately delete any cookies as they're added in the authentication flow, I get the "select provider" screen, but as expected, authentication won't proceed properly because cookies can't be saved. Is there a particular cookie name which I can purge? –  jogloran Aug 20 '12 at 23:57
    
After some experimentation, I don't think Local Storage is the culprit. Before and after authentication via Google, localStorage is empty, and I've verified that localStorage.clear() does work in UIWebView. So my suspicion is that one of the cookies is responsible for caching the user's logged-in status. –  jogloran Aug 21 '12 at 5:49
    
Specifically, the value of se-usr seems to be responsible. But never allowing it to be set breaks the authentication flow. –  jogloran Aug 21 '12 at 7:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .