As far as I remember, this has been discussed before and it's a known issue. If the current behaviour would be changed so that the 'final url' (at the end of the redirect chain) gets the Gears permissions, then worker calls to APIs such as ResourceStore::capture() would need to make sure they use origin of the 'final url' and not of the url used in createWorkerFromUrl(). I'm not sure how practical this is for Web apps. Anyway, I do agree that the current behavior seems inconsistent.
Andrei On Mon, Oct 20, 2008 at 2:51 PM, Steve Block <[EMAIL PROTECTED]> wrote: > > Hi all, > > A quick question about createWorkerFromUrl. > > If I understand things correctly, it looks like > GearsWorkerPool::CreateWorkerFromUrl grants permissions to the origin > corresponding to the worker URL, unless that origin has been > explicitly denied. Once the URL has been loaded, if the origin > corresponding to the worker's final (possibly redirected) URL does not > match the main page's origin, the worker's factory is suspended, so no > Gears objects can be created. When the worker calls allowCrossOrigin, > the factory is resumed. > > This means that if createWorkerFromUrl is called with a URL which > redirects cross-origin, GearsWorkerPool::CreateWorkerFromUrl will > grant permissions to the 'wrong' origin. When the worker calls > allowCrossOrigin, it's factory will be resumed, but object creation > will fail because the origin does not have permissions (unless > permissions were already granted). > > My question is, is behaviour this intentional? If so, should it be > documented somewhere? > > Steve >
