On Fri, Jan 31, 2014 at 1:32 PM, Joe Bowser <[email protected]> wrote:
> On Fri, Jan 31, 2014 at 8:57 AM, Bas Bosman <[email protected]> wrote: > > > > LocalStorage leverages the browser's same origin policy to ensure that > > content from other origins cannot read the token and thus cannot access > > the bridge. If we use vanilla JS there is nothing stopping the malicious > > code from reading the random # itself before calling the bridge. > > > > We're not using Vanilla JS. Tokens have to be added for all > whitelisted domains natively. This is done to solve the whole Chicken > and the Egg problem that we have with our config.xml. The value > should exist when the browser gets access to the storage, and it has > to match what it is natively, which I believed is stored in memory, so > even if the value was added in Vanilla JS, it would be caught and set > as invalid. I haven't tested that. > localstorage would allow iframes on different domains than the top one to use the bridge. I don't think that's very compelling. iframes can use postMessage() to talk to the main frame, which in turn can call exec. If you really wanted to, you could provide the token to the iframe via postMessage. Localstorage seems like overkill to me still though. I don't think there's a chicken and egg problem: State 0 - Native has no token, JS has no token State 1 - JS in main frame include cordova.js State 2 - JS in main frame generates a token, and provides it to native State 3 - Native, not already having a token, accepts it and saves it. Now both JS and native have the same token in memory without needing to go through localstorage.
