If you are using [NSHTTPCookieStorage sharedHTTPCookieStorage], then what
Chris says does apply.
But if you use this method, you shouldn't need to care about the origin of
the cookie:
/** Adds a cookie to the shared NSHTTPCookieStorage that will be sent to
the remote server. This
is useful if you've obtained a session cookie through some external
means and need to tell the
replicator to send it for authentication purposes.
This method constructs an NSHTTPCookie from the given parameters, as
well as the remote server
URL's host, port and path.
If you already have an NSHTTPCookie object for the remote server, you
can simply add it to the
sharedHTTPCookieStorage yourself.
If you have a "Set-Cookie:" response header, you can use NSHTTPCookie's
class methods to parse
it to a cookie object, then add it to the sharedHTTPCookieStorage. */
- (void) setCookieNamed: (NSString*)name
withValue: (NSString*)value
path: (NSString*)path
expirationDate: (NSDate*)expirationDate
secure: (BOOL)secure;
I don't know the exact version of the code where this was added, but if you
update to the latest version on the master branch you should be able to
call this method.
On Mon, May 19, 2014 at 2:54 PM, Michael Mayer <[email protected]>wrote:
> What you describe is what I have been trying to accomplish. My step #7
> looks like this, where responseObject is a json object I get back from the
> webapp with the cookie obtained by posting to the admin port of the sync
> gateway.
>
> NSDictionary *properties = [NSDictionary dictionaryWithObjectsAndKeys:
>
> [self dbUrl], NSHTTPCookieDomain,
>
> [[self database] name], NSHTTPCookiePath,
>
> [responseObject valueForKey:@"cookie_name"], NSHTTPCookieName,
>
> [responseObject valueForKey:@"session_id"], NSHTTPCookieValue,
>
> [responseObject valueForKey:@"expires" ], NSHTTPCookieExpires,
>
> nil];
>
> NSHTTPCookie *syncCookie = [NSHTTPCookie cookieWithProperties:properties];
> [[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:syncCookie];
>
>
> I guess I was thinking storing the cookie in the sharedHTTPCookieStorage
> would cause the replicators to automatically use it for authentication. I
> have not found an iOS API to specify the cookie to be used for
> authentication by the replicators. Am I missing something?
>
>
>
> On Monday, May 19, 2014 4:27:15 PM UTC-5, Traun Leyden wrote:
>
>>
>>
>>
>> On Mon, May 19, 2014 at 10:22 AM, J. Chris Anderson <[email protected]
>> > wrote:
>>
>>>
>>>
>>> In order for the cookie to be used, it must be set from the same origin
>>> as the sync connections are going to. So the call from your mobile code to
>>> your custom API, should be in a sub-path of the same domain and port as the
>>> sync service.
>>>
>>>
>>
>> Actually there is now a new native API call that makes the original
>> cookie domain irrelevant.
>>
>> Here's a diagram that describes the interaction of the various components
>> during a Cookie auth:
>>
>> http://cl.ly/image/0J3D0x141z2q
>>
>> In step #7, you would call this API to set the cookie:
>>
>> /**
>> * Sets an HTTP cookie for the Replication.
>> *
>> * @param name The name of the cookie.
>> * @param value The value of the cookie.
>> * @param path The path attribute of the cookie. If null or empty,
>> will use remote.getPath()
>> * @param expirationDate The expiration date of the cookie.
>> * @param secure Whether the cookie should only be sent using a
>> secure protocol (e.g. HTTPS).
>> * @param httpOnly (ignored) Whether the cookie should only be used
>> when transmitting HTTP, or HTTPS, requests thus restricting access from
>> other, non-HTTP APIs.
>> */
>> @InterfaceAudience.Public
>> public void setCookie(String name, String value, String path, Date
>> expirationDate, boolean secure, boolean httpOnly) {
>> }
>>
>> and the cookie domain will be set to the domain of the sync gateway, no
>> matter what your domain of your webapp is:
>>
>> cookie.setDomain(syncGatewayURL.getHost());
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Couchbase Mobile" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mobile-couchbase/57bd3964-22e7-4184-b4ad-cceab1916286%40googlegroups.com<https://groups.google.com/d/msgid/mobile-couchbase/57bd3964-22e7-4184-b4ad-cceab1916286%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mobile-couchbase/CACSSHCGZ_0B8mKE%2B5F%3DdN%3DpzOG1fXn1JrdD05uKZmmTmzShw4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
