cookie-based custom auth with auth server & SGW on diff host/port

[Seung Chan Lim]

I have a custom auth server I'm using to authenticate the user. I also have a sync gateway server which is on a different host/port than the custom auth server.

I get the session id through the saw which I access from within the auth server. I then send the session id back to the client, and the client uses that to sync directly with the sgw. 

When doing so, I thought I could simply send the following payload to http://lite.couchbase./_replicate and despite the difference in host/port it would work.

"{"source":"status32","target":"https://sync-dev.forksandbridges.com:4984/maum2/","continuous":true,"headers":{"Cookie":"SyncGatewaySession=7b482f00b3afcdd1e7ba2fcff4a8b2adda14927a"}}"

But I'm getting a 401... Am I misunderstanding something?

slim

[Jens Alfke]

> On Nov 18, 2014, at 6:38 PM, Seung Chan Lim <djs...@gmail.com> wrote:
>
> "{"source":"status32","target":"https://sync-dev.forksandbridges.com:4984/maum2/","continuous":true,"headers":{"Cookie":"SyncGatewaySession=7b482f00b3afcdd1e7ba2fcff4a8b2adda14927a"}}"

That looks correct. Can you verify, i.e. using some kind of packet trace or debugging proxy, that the Cookie: header you expect is actually being sent?

—Jens

[Seung Chan Lim]

Hmmm... Good catch. It's not. I assumed that it was, but I was wrong. Then am I misunderstanding something about calling _replicate?

{"source":"status32","target":"https://sync-dev.forksandbridges.com:4984/maum2/","continuous":true,"headers":{"Cookie":"SyncGatewaySession=7b482f00b3afcdd1e7ba2fcff4a8b2adda14927a"}}

The above is a json string I'm sending as the body of a POST request to http://lite.couchbase./_replicate

slim

[Jens Alfke]

> On Nov 18, 2014, at 7:42 PM, Seung Chan Lim <djs...@gmail.com> wrote:
>
> Hmmm... Good catch. It's not. I assumed that it was, but I was wrong. Then am I misunderstanding something about calling _replicate?

No; but I just remembered a detail about Cocoa's NSURLConnection class — IIRC, "Cookie:" headers that the client adds to the request will be overwritten by cookies looked up from the NSHTTPCookieStorage.

In the native API the CBLReplication class has a method to set a cookie, but in REST your only option is to specify it as a header the way you're doing, so this looks like a real problem. Hm.

I've just sent a question to Apple's networking mailing list to see if there's a way around that. Otherwise I don't have any good workarounds for you, other than somehow getting your custom auth API to appear to come from the same host/port as the Sync Gateway, so that it can use a Set-Cookie: response header.

—Jens

[Seung Chan Lim]

From the NSHTTPCookieStorage? What does that mean?

From iOS Phonegap, can I:

1) make an http request directly to my SGW with my session cookies set  (i.e. Cookie: SyncGatewaySession=blah)

2) AND THEN make a request to http://lite.couchbase./ 

When this starts replication, would it use the cookies from my first HTTP request to the SGW? Is that what you mean by looking up from the NSHTTPCookieStorage?

slim

[Jens Alfke]

On Nov 19, 2014, at 1:54 PM, Seung Chan Lim <djs...@gmail.com> wrote:

From the NSHTTPCookieStorage? What does that mean?

Nothing, unless you know the Cocoa networking APIs. I was mostly talking to myself about the underlying cause of the problem.

From iOS Phonegap, can I:

1) make an http request directly to my SGW with my session cookies set  (i.e. Cookie: SyncGatewaySession=blah)

2) AND THEN make a request to http://lite.couchbase./ 

When this starts replication, would it use the cookies from my first HTTP request to the SGW? 

I don't think so. Sending a Cookie: header in a request doesn't register it with the system cookie storage; it's receiving it in a Set-Cookie: response header that registers it.

I filed this as issue #532, btw.

—Jens