[whatwg] Accessing cookies from workers

[Drew Wilson]

In my particular case, I'm trying to figure out how to use cookie-based
authentication from workers.
I could use postMessage() to a main window to set cookies. However, I have
another motivation for exploring this: my team is planning to experiment
with persistent workers (workers that continue running even after all
entangled windows are closed). In that case, there may not be any window you
can use to set cookies. I'll send more about this in a separate thread.

Finally, there's one thing you can do with cookies that I don't think you
can do with local storage: share data with other subdomains (i.e. if I'm
running code under foo.example.com, I can write a cookie with 'domain=.
example.com' and it'll be visible to code running under
bar.example.comalso). This is useful for things like single sign-on
authentication.

-atw

On Thu, Mar 5, 2009 at 5:42 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman <michaeln at google.com>
> wrote:
> >> Allowing cookie to be set would unfortunately create a synchronous
> >> communication channel between the worker and the main window. This is
> >> something that we need to avoid to prevent users from having to deal
> >> with locking and other thread related issues.
> >
> > Hmmm... the cookie setting API could be async in workers.
>
> Or you could just use postMessage() and ask the main thread to do it?
>
> What is the use case for reading/writing cookies though? Could use use
> localStorage instead (once we figure out a different API for it that
> doesn't have the shared-state problem that the current API has)
>
> Even just synchronous read access has race-condition problems. For
> example the following script:
>
> if (docCookies == "hello") {
>  doStuff();
> }
> else {
>  log("cookies certainly aren't 'hello', they are: " + docCookies);
> }
>
> could result in "cookies certainly aren't 'hello', they are: hello"
> being printed.
>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090305/a758711b/attachment-0002.htm>