Quick thing; you should expose not just the origin, such as example.com, but
the scheme (https/https) and the port. Probably just use the same
termininology as the window.location object, such as worker.location,
worker.location.scheme, worker.location.port, etc.
On Thu, Sep 11, 2008 at 5:10 PM, Nigel Tao <[EMAIL PROTECTED]> wrote:
>
> A .js file intended to be used in a worker can check an incoming
> message.origin before it calls allowCrossOrigin, but currently (unless
> I've missed something) a worker can't discover its own origin [1].
> Thus, you can do something like, "I'm hosting my code on example.com,
> so my .js file will do an explicit comparison with that hard-coded
> string", but not, "here's some generic, cross-origin aware worker
> code, feel free to copy to your website".
>
> So, I'm thinking of adding an origin property on the workerpool, so
> that you can, in a worker, do things like
> google.gears.workerPool.onmessage = function(a, b, msg) {
> if (msg.origin != google.gears.workerPool.origin) {
> return;
> }
> google.gears.workerPool.allowCrossOrigin();
> // do more stuff
> }
>
> This is trivial to implement, since every gears module knows its own
> SecurityOrigin (via its ModuleEnvironment).
>
> Any comments? One thing is that, IMHO, an origin is more a property of
> the factory than a workerpool (and that allowCrossOrigin should have
> been a method on a GearsFactory, not a GearsWorkerPool), but since
> allowCrossOrigin is already on a GearsWorkerPool, I thought to keep
> the origin property on the same thing.
>
>
> [1] Well, I suppose it could sendMessage to a range of ints, hope that
> one of those outbound messages is delivered to itself, and then check
> message.origin of the message it sent to itself, but, yuck.
>
--
Best,
Brad
[EMAIL PROTECTED]
