I could be wrong, but I think we also discussed preventing cross-origin redirects when fetching a worker URL.
That way, the behavior would be predictable _and_ we would never grant permission to the "wrong" origin. On Mon, Oct 20, 2008 at 8:05 AM, Andrei Popescu <[EMAIL PROTECTED]> wrote: > > 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 >> >
