W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [IndexedDB] How to recover data from IndexedDB if the origin domain don't exist anymore?

From: <piranna@gmail.com>
Date: Wed, 16 Jan 2013 00:57:48 +0100
Message-ID: <CAKfGGh1UPKX0kH6GymJ9deRdE5xOW8W9rZZvGag=LQnyjPh20Q@mail.gmail.com>
To: "SULLIVAN, BRYAN L" <bs3131@att.com>
Cc: Todd Blanchard <toddvblanchard@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
I have keep thinking about this topic and found a good solution: implement
a CORS-like functionality.

This way, when an IndexedDB database is created for the first time (like
when browser ask to the user if s/he allow that the page store data on this
machine) the developer could define an optional 'accesscontrol' parameter
with an object defining the access control mechanism in the same way it's
defined with CORS, and on later access when the database exist already
access is checked against this previously defined accesibility (don't
allowing to overwrite it) and check if we are allowed to access to the
database or not. By default it would work as up to now, but for example on
my problem when creating the database I would define an "accesscontrol =
{alloworigin: '*'}" attribute so everybody would access to it, maybe having
a list of pages that tried to access to the database and showing the
browser an alert when a new one want to access to it.

As an extension, later it would be interesting to allow to change that
accesscontrol attribute. I believe a good place for this would be the
onversionchange event, and only allow to change it to the allowed domains.
This way, on my example I would define two or three "backup" origin domains
beside the one that created the database as allowed so if the main one
disappeared, I would connect to one of this another ones that have access
to the IndexedDB database and there recover my data or update the
accesscontrol attribute removing the disappeared domain or add some another
new ones.

Also, this functionality would be implemented on other objects like
localStorage or Filesystem API. Another possible implementation it's about
define the CORS on some meta tags as Bryan suggested, that could be useful
to define that CORS funcionality for all the objects on the webpage, and it
wouldn't be incompatible with my idea allowing a more fine-grained access
permissions, so they would be complementary.

Ideas? Doubts? Comments? :-)


2013/1/9 piranna@gmail.com <piranna@gmail.com>

>
>> Perhaps what we need (and I am ducking as I say this) is a meta tag for
>> web pages, e.g. ****
>>
>> <meta name="previously-known-as" content="http://olddomain.com:80">****
>>
>> or ****
>>
>> <meta name="same-as" content="http://olddomain.com:80">****
>>
>> ** **
>>
>> This could then be used by the browser to allow the user (always in
>> control of such decisions) to grant the new origin to take ownership of (or
>> at least gain read/write access to) any existing data of the old origin.*
>> ***
>>
>> **
>>
> PubNub API has the hability to add a 'origin' argument on its constructor (
> http://stackoverflow.com/questions/12843178/cant-publish-via-pubnub-origin-is-not-allowed-by-access-control-allow-origin,
> the page it's from Stackoverflow but show a similar problem and it's solved
> by PubNub staff, so I think it shows correctly how it works) that's the one
> asociated with the database, and my proposition was more related on this
> way, altohugh don't know up to what point it's not standard way to do
> things.
>
> Related to your proposition with meta-tags, content attribute would be
> filled via Javascript so users would set the URL of the non-existent domain
> (by hand or a pre-filled dropdown list)? Obviously, asking for permissionsn
> before accessing to it...
>
> And also regarding to permissions, it would be good to see about just
> allow read access to the database on other domain (for example for backup
> and/or copy it's content on the new domain database), take ownership of the
> database from the old domain on the new one (like "upgrading" it with your "
> previously-known-as" meta-tag example) or directly allow plain sharing of
> the database between several web domains (like with your "same-as" meta-tag
> example or a sharing "magic word", for example like indexedDB.open('myAwesomeDatabase',
> 'Hocus Pocus magic word')). This last point would be the most dangerous
> since would open a door por web advertising like the one that happened with
> cookies, but maybe it would be solved allowing to the databases only be
> opened as "shared" if they are invoked from the current page domain instead
> of third party ones (something like the filter on the browser to don't
> allow third party cookies).
>
>
> --
> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
> monton de sitios diferentes, simplemente escribe un sistema operativo Unix."
>  Linus Tordvals, creador del sistema operativo Linux
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
 Linus Tordvals, creador del sistema operativo Linux
Received on Tuesday, 15 January 2013 23:58:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT