Authentication issues with Facebook session

[Christoph Berlin]

Hi,

we have been struggling with this issue for a long time now and debugged pretty much every piece of code we wrote in order to find the root cause. Issue:

1) User logs in via Facebook and uses the Token based authenticator to authenticate with the sync gateway.

2) User logs out and logs in with a basic HTTP authenticator

Problem: even though the authenticator is correctly configured and the logic is sound, the first authentication attempt happens under the old Facebook user and hence the replication is messed up. 

At first, we thought that it must be an issue on our side and therefore we spent days troubleshooting but now we found evidence that something else is going on. We delete the database, we deallocate every object that is remotely related and still the issue occurs. Here are a few scenarios that have been tested:

1) Basic to Basic Authentication works

- Basic HTTP user logs in and out

- Another basic HTTP user logs in and it works as expected

2) Basic to Facebook authentication

- Basic HTTP user logs in and out

- A Facebook user logs and it works as expected

2) Facebook user and restarting the app

- Facebook user logs in and out

- App is restarted

- Basic HTTP user logs in and it works as expected

The problem is the Facebook session in combination with the CBLManager.

When a Facebook user logs in and out, the immediate next user who tries to logs in still get the old Facebook user's context. Even when flushing the Facebook session it didn't change the behavior...it seems that if another user tries log in after a FB user has been authenticated the issue occurs. But it is solely memory based because restarting the app eliminates the issue...

We then suspected that the CBLManager might be the root cause as this is the only process that doesn't get deallocated. We found a bug on GitHub regarding session cookies and then tried to clear any cookies manually - that worked!

So here is what we do in order to work around the problem:

1) Facebook user logs in and out

2) At logout, run

    for (NSHTTPCookie *cookie in [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies])  [[NSHTTPCookieStorage sharedHTTPCookieStorage] deleteCookie:cookie];

3) Immediately log in with a Basic HTTP and voila, its working...

Is that expected? Is that a bug? I find it hard to believe that no one else is running into this...

Thanks Christoph

[Jens Alfke]

On Mar 26, 2015, at 8:36 AM, Christoph Berlin <hoptoawe...@gmail.com> wrote:

1) User logs in via Facebook and uses the Token based authenticator to authenticate with the sync gateway.

2) User logs out and logs in with a basic HTTP authenticator

Problem: even though the authenticator is correctly configured and the logic is sound, the first authentication attempt happens under the old Facebook user and hence the replication is messed up. 

It sounds like the Gateway session cookie is still being sent and is overriding the basic-auth credentials. (You can verify this by sniffing the HTTP traffic using something like Charles.) I would think that the Gateway would check basic auth first, but I haven’t looked at that code in a long time. I suggest filing a bug against the Gateway.

We then suspected that the CBLManager might be the root cause as this is the only process that doesn't get deallocated.

I don’t think so. The CBLManager has nothing to do with replication.

It makes sense for the replicator to clear session-related cookies when it’s using basic auth. The problem with that has been that the cookie store (NSHTTPCookieStorage) is a global shared by the entire app, so if one replicator did this it could destroy state used by another replicator. Pasin recently implemented a custom per-replicator cookie store that should fix this.

—Jens

[Christoph Berlin]

Thanks Jens, we just verified and can confirm that its using the previous session details…

Do you have any idea when this custom cookie storage will make it into the release? Next one?

https://github.com/couchbase/sync_gateway/issues/758 filed…

Thanks Christoph

--
You received this message because you are subscribed to a topic in the Google Groups "Couchbase Mobile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mobile-couchbase/yMvUxXM4Ncg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/FB051F0A-0480-4D2E-B95F-59AC1CBEA190%40couchbase.com.
For more options, visit https://groups.google.com/d/optout.

[Jens Alfke]

On Mar 26, 2015, at 8:09 PM, Christoph Berlin <ma...@christophberlin.com> wrote:

Do you have any idea when this custom cookie storage will make it into the release? Next one?

It isn’t in 1.0.4 (which should be released in the next day or two). The next milestone after that is 1.1, which on iOS has a megaton of major changes and is at least a month away.

It’s possible you could create a custom build by checking out the v1.0.4 tag and cherry-picking the commit that added the cookie store, but there might be a lot of merge conflicts to work out.

Your workaround of manually removing cookies from the OS cookie store sounds reasonable. You don’t have to get rid of all of them, just the ones with the server’s hostname.

—Jens