remotestorage / remotestorage.js Goto Github PK

right now our register page doesn't accept user_address and redirect_url from the get query, so it's not obeying http://www.unhosted.org/spec/dav/0.1/index.html#registration

this issue represents the problem that is discussed on the mailing list in this thread http://groups.google.com/group/unhosted/browse_thread/thread/5e20e981165fd3a7
as long as we have no way to allow multiple oauth tokens to access the same resource with the same username, either by getting it working in http://unhosted.org/spec/dav/0.1 or by putting something into version 0.2 that makes it possible, this bug should stay open.

the login flow is confusing now if you visit a second unhosted website: it will ask for a user address and password, and it is far from obvious that the user address is the one you already have, but the password is a new, per-app password.

by putting this app password registration behind the oauth dialog, or even inside the app ('go crypto if you want to'), we hope this login flow becomes less confusing. the 'app-pwd-optional' branch was created for this purpose.

right now, in updateNode we do node.data = JSON.stringify(node.data) and then in getNode we do node.data = JSON.parse(node.data) again. This way, node.data is always stringified as it is on the wire. but of course this is hacky and inefficient. we should make 2 localStorage items per data item: one with the item content (always a string, directly in localStorage and not double-JSON-ed), and the other with all the metadata, so the whole node object with all its fields except node.data.

CouchDB can return a 409 on DELETE, we need to handle that and retry with the right _rev in there probably

As title. At /unhosted/wappside/genkey/genkey.html entering http://example.com/ makes the JS POST to http://http//example.com//unhosted/cloudside/unhosted.php

(note double slash as well)

This confused me for a while, as it wasn't documented, and I'm used to forms detecting if I've added the http:// prefix.

When using the widget from the developer preview of remoteStorage I get the following error:

Uncaught TypeError: Object #<Object> has no method 'discoverStorageInfo' (line 1557 of latest/remoteStorage-debug.js)

It looks like:
discoverStorageInfo is called from https://github.com/unhosted/remoteStorage.js/blob/v0.7/src/lib/widget.js#L141 but doesn't seem to ever be defined on the session object https://github.com/unhosted/remoteStorage.js/blob/v0.7/src/lib/session.js#L138

There are also two definitions of discoverStorageInfo in the same scope
https://github.com/unhosted/remoteStorage.js/blob/v0.7/src/lib/session.js#L26
https://github.com/unhosted/remoteStorage.js/blob/v0.7/src/lib/session.js#L84

Right now defineModule calls the builder immediately, storing the module instance in an object. Once loadModule is called, the instance gets added to the remoteStorage object, and access is claimed on the corresponding paths. One reason to call the builder immediately within defineModule, is that this way module information (such as it's dataHints) is available without loading the module (which IMHO should be referred to as enabling the module, as it doesn't really load anything - the code has to be loaded already).

Now this brings trouble when the module wants to do initialization, that involves data. For example the calendar module calls privateBaseClient.sync('/'). This brings two problems:

1. in this specific case, this creates an empty directory node "calendar/", which confuses my tests
2. data is being accessed without claiming access to the directory. In reality this line probably won't do anything, because at the point where the module is defined, access cannot have been claimed, unless the user was just reloading the page, being connected already.

I can think of two ways to solve this:

1. introduce a module initializer, that is called once the module is loaded
2. only call the builder, when loading a module.

I prefer (1). Any thoughts on naming? initialize? onload? Anyway, it probably shouldn't be part of the exports but an additional key to the module's definition.

I just realized that I have been loading the root module in read mode this whole time:

remoteStorage.loadModule('root', 'r');

This allows me to add things to the remoteStorage despite missing the 'w' flag. This is remoteStorage using Local Storage only.

In line 420+, syncer/include.js calls the onChangeHandler for all items in all collections.
It gets called with wrong arguments:

• "key" is the index in the array of items instead of the actual key
• "newValue" is null, as getItem is called with the invalid key as well.

This is due to getCollection, which doesn't return any keys. Michiel mentioned in the channel, that in the original usecase this wasn't needed, as the items had their key duplicated as an "id" attribute. Depending on this may or may not be a good idea.
Either way, the bug described above is still a bug.

Currently, when you use an unhosted app and press Ctrl+S out of habit, the annoying save website popup comes up.

Instead, since people probably want to save the thing they work on right now, Ctrl+S should force a synchronization with the remoteStorage.

This would allow the user to use the app without any unhosted server

http://diveintohtml5.info/storage.html

right now, the callback url from the oauth dance will send the token to the app provider. we can probably avoid this if we use the url fragment instead.

I'm working on a remoteStorage server -- http://github.com/jcoglan/restore -- and the token I generate contains a pipe character (|). I embed this in the redirect URL as %7C since the fragment part of the URL is essentially being used as a query string. When the client sends to token back to me to read the user's data, the character is still escaped in the Authorization header -- it is sent as %7C when it should be sent as |.

The remoteStorage client should correctly query-string-parse the URL fragment to get the access token, using decodeURIComponent() to do so. It should not URI-encode the token when sending it as a header value.

This is a fun one! The idea is to create say 5 different login and register UIs and icons. Then go to a mall or something with our laptops, and ask random people 'do you have a moment to try out this fake app and tell us if we're on the right track?'

css change

when one app has a resource, and another app wants to access that data, then we need some good UI that makes sure the user knows which app has access to which data. we will probably need to introduce a control panel on the storage node to keep track of oauth tokens you've given out to various apps for various resources. or maybe one app should oauth to another app, to make the flow more similar to that of web2.0 apps sharing data. either way, we need to experiment with this

this is a trace of what it does now, the lines

get-call handleChild /tasks/todos/ remoteStorage-debug.js:1172
get-cb handleChild /tasks/ remoteStorage-debug.js:1174

indicate that it's choosing the wrong cb imho. also it seems to be piling up cb's as you see at the end the failing DOM update event repeated 6 or 7 times

syncNow / remoteStorage-debug.js:1227
pullMap  remoteStorage-debug.js:1203
pullMap  calling handleChild for / remoteStorage-debug.js:1219
handleChild / remoteStorage-debug.js:1147
pullMap / remoteStorage-debug.js:1203
pullMap / calling handleChild for tasks/ remoteStorage-debug.js:1219
handleChild /tasks/ remoteStorage-debug.js:1147
get-call handleChild /tasks/ remoteStorage-debug.js:1172
pullMap / calling handleChild for public/ remoteStorage-debug.js:1219
handleChild /public/ remoteStorage-debug.js:1147
pullMap /public/ remoteStorage-debug.js:1203
pullMap /public/ calling handleChild for tasks/ remoteStorage-debug.js:1219
handleChild /public/tasks/ remoteStorage-debug.js:1147
get-call handleChild /public/tasks/ remoteStorage-debug.js:1172
get-cb handleChild /public/tasks/ remoteStorage-debug.js:1174
pullMap /public/tasks/ remoteStorage-debug.js:1203
get-cb handleChild /tasks/ remoteStorage-debug.js:1174
pullMap /tasks/ remoteStorage-debug.js:1203
pullMap /tasks/ calling handleChild for todos/ remoteStorage-debug.js:1219
handleChild /tasks/todos/ remoteStorage-debug.js:1147
get-call handleChild /tasks/todos/ remoteStorage-debug.js:1172
get-cb handleChild /tasks/ remoteStorage-debug.js:1174
pullMap /tasks/ remoteStorage-debug.js:1203
pullMap /tasks/ calling handleChild for todos/ remoteStorage-debug.js:1219
handleChild /tasks/todos/ remoteStorage-debug.js:1147
get-call handleChild /tasks/todos/ remoteStorage-debug.js:1172
get-cb handleChild /tasks/ remoteStorage-debug.js:1174
pullMap /tasks/ remoteStorage-debug.js:1203
pullMap /tasks/ calling handleChild for todos/ remoteStorage-debug.js:1219
handleChild /tasks/todos/ remoteStorage-debug.js:1147
get-call handleChild /tasks/todos/ remoteStorage-debug.js:1172
get-cb handleChild /tasks/todos/ remoteStorage-debug.js:1174
Uncaught TypeError: Cannot read property 'title' of undefined app.js:133
get-cb handleChild /tasks/todos/ remoteStorage-debug.js:1174
Uncaught TypeError: Cannot read property 'title' of undefined app.js:133
get-cb handleChild /tasks/todos/ remoteStorage-debug.js:1174
Uncaught TypeError: Cannot read property 'title' of undefined app.js:133
get-cb handleChild /tasks/todos/ remoteStorage-debug.js:1174
Uncaught TypeError: Cannot read property 'title' of undefined app.js:133
get-cb handleChild /tasks/todos/ remoteStorage-debug.js:1174
Uncaught TypeError: Cannot read property 'title' of undefined app.js:133
get-cb handleChild /tasks/todos/ remoteStorage-debug.js:1174
Uncaught TypeError: Cannot read property 'title' of undefined app.js:133
get-cb handleChild /tasks/todos/ remoteStorage-debug.js:1174
Uncaught TypeError: Cannot read property 'title' of undefined

The readme should contain the information from http://groups.google.com/group/unhosted/browse_thread/thread/7d942b9c1a6fedc3 . Additionally, it mentions server.js which does not exists (here) any more.

Hi

why the addition of protocol check (http|https)? I use remoteStorage.js in an Android webview with local/bundled (html and js) files and a custom intent filter schema for catching the callback and pass control back to my app.

It would be nice to keep the unhosted idea and not have to have the callback on a http/https resource?

Docrastinate now gives an error when trying to connect to my 5apps remoteStorage. The redirector kept reloading and appending »#error=invalid_client« to the web address, resulting in:

http://localhost/docrastinate/syncer/dialog.html#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client#error=invalid_client …

The console looked like this:

ready state changed to: /docrastinate/syncer/include.js:13
Object
/docrastinate/syncer/include.js:13
XHR finished loading: "http://50.116.62.47/js/chromeServerV45.js".
XHR finished loading: "https://5apps.com/.well-known/host-meta".
XHR finished loading: "https://5apps.com/webfinger?q=acct:[email protected]".
ready state changed to: /docrastinate/syncer/include.js:13
Object
/docrastinate/syncer/include.js:13
XHR finished loading: "http://66.228.34.50/js/chromeServerV45.js".
XHR finished loading: "https://5apps.com/.well-known/host-meta".
XHR finished loading: "https://5apps.com/webfinger?q=acct:[email protected]".
ready state changed to: include.js:13
Object
syncing: false
proto: Object
include.js:13
XHR finished loading: "http://50.116.62.47/js/chromeServerV45.js".
XHR finished loading: "http://66.228.34.50/js/chromeServerV45.js".
GET http://proxy.unhosted.org/irisCouchCheck?q=acct:[email protected] include.js:3
ready state changed to: include.js:13
Object
include.js:13
ready state changed to: include.js:13
Object
include.js:13
ready state changed to: include.js:13
…

Eventually showing on the page:
»Oops! That didn't work for "[email protected]". Are you sure you have remote storage at that address? If not, get a user address with remote storage.«

Any idea?

This happened several times already, and there is no error in the console. What happens is:

1. I click the connect button
2. the input field appears
3. after some seconds, either while typing or before having typed (when explaining it in a demo) the field disappears again.

Not sure why that happens – does anyone have the same problem?

we came up with terminology in which a federated unhosted website (installing the current sdk, so that you get a storage node and a demo app) is a 'flower', and users are like 'bees'. in this analogy, if you are the IT team of some organization and give out unhosted accounts to your employees, then the install script should only install the storage node, and not the demo app. otherwise it's confusing. so the install script should give the option :install as flower (default) or :install as hive (no app, only storage node).

when an item is deleted, it should stay marked in the store as an outgoing change, but no longer be returned by getListing.

I'm including https://github.com/unhosted/remoteStorage.js/raw/master/build/latest/remoteStorage.js on my page and calling this causes an error:

remoteStorage.getStorageInfo('jcoglan@localhost:4000', function(error, info) {
  console.log(error);
  console.log(info);
});

// -> Uncaught ReferenceError: err is not defined 

I've added remoteStorage to a little to do list app I'm working on. I ran it locally, hooked it up to iris couch, and added some items. I see them in the iris couch db editor.

Then I put my app online at http://ggtodo.googlecode.com/hg/index.html. When I connect to the same iris couch db, it says it's syncing in the console, but my data from iris couch isn't showing up in chrome's local storage browser.

Am I misunderstanding how this should work or is something broken?

Outside of the wiki, I've edited the UJ-0.2 Protocol after having a look at 0.1, the REST verb wikipage.

Changes:
Added the concept of an endpoint, so a single server can host multiple instances of unhosted storage nodes.

Pushed the different UJJP methods into HTTP methods plus URI path elements. Pushed user and key into the URI path (and out of reqeust properties).

Clarified HTTP Methods vs UJJP Methods.

please see:

• Just the diff between my edits and the wiki page
• Full text in wiki syntax
• Full text in HTML

See Jon Spriggs post in 11th weekly milestone thread on ML

After following all of the directions to begin the wappblog app, I have arrived at the point where there is a textbox where I can enter my "first blog post" (http://helloblog.com/unhosted/wappside/examples/wappblog/admin/editor.html).

When I press the "unhost this blogpost!" submit button, I get an alert box that says:

ERROR:
please define a method inside your command

What have I done wrong?

someone said that XRD files like the webfinger files we use need a signature or something. if so, we should add that to make sure our code complies with the standard

I thought Opera is a nice new HTML5-browser, most of the stuff should just work. But the non-async XMLHTTPRequest in webfinger.js doesn't seem to want to work in Opera. It seems to tell javascript it came to readystate 2, but no request is sent on the wire so it seems.

Currently, there is no license specified. Some time it used to be AGPL+MIT dual-license, but because of possible confusion and also because jQuery just dropped the MIT license, we should only have it under MIT: http://blog.jquery.com/2012/09/10/jquery-licensing-changes/

Currently the files all just have the naked code in it, we should put a header like jQuery does:
/*! jQuery [email protected] jquery.com | jquery.org/license */

/* remoteStorage.js 0.7.0 remoteStoragejs.com, MIT-licensed */

in /.well-known/host-meta, the links are not https, even if you install over https.

There's a typo in the website URL: it should be www.unhosted.org, instead of www,unhosted.org

My current plan is this:

• Use cucumber with selenium
• Test against various storage providers
• Do the following tests:
  1. Visit a (test-)app, connect via widget, sign in at storage provider, perform test-requests (list->get->set->list->get->delete->list, get)
  2. Perform test requests against local storage (i.e. without being connected to remoteStorage)
  3. Perform test requests, then connect, do them again, then take remoteStorage provider offline, do the test requests again, take the provider back online, then check validity of the data.

If anyone has any input on this, I'd appreciate it :)

Hi,
Maybe you already thought of this, but I can't quite make it out from the code...

For friendsunhosted, we get the public data from all of the friends for a user, and for the user.

It would be awesome if all the remoteStorage connections (r/rw and localStorage caching integration etc) allows for creating one instance per storageId.

I guess this means that something like the syncer in 0.6.9, or generally the application access point, would export a function like:

return { createCachedSynchedStore: function(storageId, ...) { 
    self.storageId = storageId;
    return {
        get: function(category, key) ...,
        listKeys: function(category)
        set: function(category, key, value) ...,  // will fail for unauthorized users
        on: function(event, listener) ... ,
        ...
    };
};}

and that any localStorage cached keys would also contain the storageId to avoid collisions.

This way, in friendsunhosted, we can create such a store for the main user, then get all his friends, and create the similar store (read-only) for all his friends, and get all the caching etc in exactly the same way.

Does this make sense? Is it like this already? Or do you have something better?

Thx!

There needs to be a state in the syncer signifying offline state. It should be like the small popout on the left like when you hover over it for logout, except that it is permanent and states »offline« or something similar.

Additionally, we probably need to explain or somehow fix that if you sign out while offline, your changes will not be synced up.

the install instructions mention nothing about https, yet in production, all unhosted storage nodes should run only over https. we had this working at some point, iirc it's just a2enmod ssl and then in the apache config turn on ssl and indicate the path to the 3 files that startssl.com gives you. we have certs for wallet.myfavouritesandwich.org and for dev.unhosted.org, which i will install again once we put this back into the install instructions - that way we can test the install instructions too.

Is there any way that one can retrieve binary files (images, videos, etc) and view them in HTML?

This is a really cool project and I'm excited to see you build it.

I got the demo text editor working and now I'm trying to add it to a web app I have that stores stuff in localStorage. I added http://unhosted.org/remoteStorage.js to my app and ran it in a browser where it already had stuff in localStorage. I connected it to my iris couch db. When it starts up it said:

GET http://yourremotestorage.net/CouchDB/proxy/dbenamy.iriscouch.com/ggtodo/u_shadowIndex 404 (Not Found)

and wouldn't created anything in couch db. Once I made a change, it created everything.

I had a syntaxerror in the produced xml file. (forget the "?" on the end "?>" of the first line )

I think it could be tested if you look at the parseerror property of the returned document

this one's probably for edokoa. some pages, like the install page, have no css at all, and others have been subject to 'css rot'

Hi,
I am one of the developers at Mozilla working on BrowserID. I want to inform you for your BrowserID version of myfavoritesandwich.org that the assertion verification is changing from GET to POST. The reason is so that we can better anonymize our logs with respect to user data, GET requests can be logged, with the full assertion data, at several levels, whereas a POST's data is normally not logged. Your assertion verification call to browserid.org/verify should be updated as soon as possible. We are going to have a sunset period at least until next Tuesday to give sites a chance to update this without breakage. If you have any questions or comments, please send me a private message!