Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web access to files #14

Open
entropitor opened this issue Mar 23, 2014 · 7 comments
Open

Web access to files #14

entropitor opened this issue Mar 23, 2014 · 7 comments

Comments

@entropitor
Copy link

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
Copy link
Contributor

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
Copy link
Owner

jcoglan commented Mar 5, 2015

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
Copy link

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
Copy link

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
Copy link
Contributor

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
Copy link

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

@michielbdejong
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants