search

jcoglan / restore

Simple remoteStorage server written in Node.js
293 stars 27 forks source link

Web access to files #14

Open entropitor opened 10 years ago

entropitor commented 10 years ago

It would be nice if we could login in into restore and look at

  1. The applications that have access to our files (and add a possibility to revoke them).
  2. The files themselves.
michielbdejong commented 10 years ago

a UI for listing and revoking access tokens is indeed missing from reStore.

for the files themselves you can use export.5apps.com, remotestorage-browser.5apps.com, or a similar app.

jcoglan commented 9 years ago

Sorry I didn't have time to look at this when you posted it.

I think access to files is out of scope, since that can be done using a client application with the root:rw scope.

Administering authorizations is certainly necessary but I think it should possibly be a separate application. Since that would involve using sessions, it would complicate the security considerations of reStore itself, which currently does not use sessions anywhere. And, whereas reStore is implemented on top of the bare Node http module, something with sessions and UI stuff would be easier built on top of something like Express.

Such an application could be built on top of the reStore backend storage engine abstraction as it stands, I believe. Are there any methods we'd need to add to that interface to facilitate an app like this?

untitaker commented 8 years ago

It'd be nice if reStore recorded a last-used date on authorization, so a potential interface could automatically revoke old tokens. I think this would be a great UI in addition to grouping authorizations by redirect URI.

untitaker commented 8 years ago

However, I don't think separating the administration interface from the storage engine is a good idea from a user's perspective. Perhaps I am misunderstanding this, but this new application would probably run on a new port? I suspect that would complicate matters for people who run restore behind a reverse proxy (eg myself)

michielbdejong commented 8 years ago

The admin interface would have to run on a separate port, or if on the same port then at least without CORS headers, to avoid exposing its cookie to applications on other origins, which are allowed to access the API but not the admin interface.

untitaker commented 8 years ago

Is there a security problem in just sending different/no CORS headers for the OAuth and admin paths?

michielbdejong commented 8 years ago

I think it should be ok, so then you don't need two separate ports! :)