I’ve been trying to use remote storage as a backend for an ebook library and reader. I just hit a roadblock with images embedded in the ebooks. I’m dealing with EPUB3 which is just html files.
Long story short, remotestorage auth requires an Authorization header be sent with every request. I can’t add a Header to every single request because many requests are made by the browser instead of ajax. It would be awesome if remotestorage supported the URI query parameter method for using bearer tokens. This is part of the OAuth 2.0 spec. http://tools.ietf.org/html/rfc6750#page-6
We’ve been discussing this a bit in the past, and some servers (notably @fkooman’s PHP server) allow this already. It even made it into the new spec version, which will be published today! But only as an optional feature:
In addition, providing the access token via a HTTP query parameter for GET requests MAY be supported by the server, although its use is not recommended, due to its security deficiencies; see [BEARER, section 2.3].
At my own company (we’re running 5apps and its remoteStorage offering 5apps Storage), we’ll look at adding support for this as soon as possible, but obviously there are security concerns that we first have to evaluate properly.
Thanks for your response. Like I said, this is a roadblock. By that, I mean I can’t use remotestorage because of this limitation. I don’t think the workaround is feasible for my project for a variety of reasons. Primarily, It would take a lot of work to re-architect at this point and also it’s a reference implementation for EPUB and I don’t want to put in a bunch of remotestorage specific hacks to make it work.
ideally, I would like you to take it a step further and only require the bearer authentication once per session. That way img urls worked transparently. For example, if I try to access a restricted resource I get a 401 challenge, I respond with the bearer token, then I’m “logged-in” with a session cookie for however long. I can’t find anything in the OAuth 2.0 spec that would prohibit this workflow. It’s also how most of the web deals with authentication and it has built-in browser support. You log in once and obtain a session cookie that times out after a period of time. This is my ideal scenario.
It’s not the end of the world for my project, I just thought you might appreciate some feedback from a real-world application trying to integrate remote storage. Consider it a data point.
With regard to the security concerns, I can’t really comment directly since I’m no expert and I don’t have time to properly research the relevant issues.
From my point of view as an application developer, I can say that there is a balance between usefulness and security that you need to find. When security gets in the way of building applications, less people will use it. Remember, remotestorage is an API first unlike Dropbox and Google Drive.
I don’t see how you would have to add it to the reference implementation at all. You’d just need to add the token to image URLs afterwards in a single function. I’ll explain further down.
With remoteStorage (and other storage protocols as well) there is no session. As the provider is separated from the app, there is no one way of how a log-in works across providers. That’s why we use token-based authorization.
Ok, sure. Thanks!
It’s a bit sad of course that you wrote it as a feature request, and we actually just shipped your requested feature, but it’s not helping you with the app after all.
Actually – and I’m really not nit-picking here – Dropbox and Google Drive are APIs, while remoteStorage is first and foremost a protocol (with an API added by a reference client library, which is only one way of using the protocol).
So there are 2 points, where we can ensure and improve usability: the protocol layer (remoteStorage specification), and the client library (remoteStorage.js). In this case, we added the feature to the protocol in order to make use cases like yours possible in the first place.
Now the question (which also touches your decision) is: how can we make it easy to use the protocol feature in an app, either via the client library or application code?
I think in this case, it would be quite easy to append the token to all asset URLs in a single function when loading a document. The same function could use the fallback I described for servers with the old spec version (probably not needed for long, though, so maybe not even necessary). I can’t think of a useful way of adding this to remoteStorage.js itself at the moment, but maybe that’s also an option.
In any case, thanks a lot for reporting the use case! It’s very helpful. Feel free to ask any question on your mind and open as many topics as you want, if you like the idea of remoteStorage in general and want to help us improve it for everybody.
Re-reading our conversation, I was actually a bit wrong with how I described the remoteStorage protocol. remoteStorage is basically re-using existing protocols and combining them in a smart way. So it’s kind of a meta-protocol.
We obviously didn’t really add the token parameter feature to the protocol, but rather allowed the OAuth protocol feature to be used by remoteStorage clients and servers. So, the text that says it is not recommended due to security concerns, is actually straight from the OAuth spec.
This might have been a misunderstanding here. We actually anticipate it to be implemented by most providers and we don’t actively discourage using that feature. Nonetheless it still requires security evaluations for every provider in the context of their infrastructure, so that no tokens end up in logs and other places.
