search

fossar / selfoss

multipurpose rss reader, live stream, mashup, aggregation web application
https://selfoss.aditu.de
GNU General Public License v3.0
2.38k stars 345 forks source link

read only token #1045

Open nzasch opened 6 years ago

nzasch commented 6 years ago

Hi! in a private instance of selfoss it would be nice to have a way to view feeds without exposing the login credentials, for example in a bookmarked url. I think that a configurable GET token can be a good way to do this.

many thanks!

jtojnar commented 6 years ago

Could you describe in more detail what is your use case?

For example:

or

nzasch commented 6 years ago

hi my concern is to not store (and use/expose) credentials on read (for example on a mobile device). it's ok to have to login when adding sources and making changes.

The second example can be an extension of the first. If it is possible to store multiple read-only credentials then one can show his feed to friends!

thanks

jtojnar commented 6 years ago

I still do not understand what your threat model is. The web frontend only uses the credentials for the initial authentication, subsequent requests use a temporary session cookie. Now, we might add a more standard auth method to the public API but session cookie already works.

The two examples are quite distinct in my mind. In the first one, the request was driven by personal convenience – it would be basically a “Remember me” feature and using longer-term tokens than session cookie would be necessary. In the second one, the key would be shared around and also passed from the app URL to the API, requiring a more strict management.

nzasch commented 6 years ago

Thank you for your reply and patience :) My threat model is to leave write credentials (user/pass or session cookie) in a possibly insecure device (mobile, iot) I use daily to read feeds. You can view it as a disposable (and revocable) read-only credential.

If one can manage many such credentials, and they can be passed inside the URL, then he can pass them to friends. I am not directly interested in this second scenario, although I think it will be a nice feature.

funwhilelost commented 6 years ago

@jtojnar The common model I've seen for this is a user is able to create any number of bearer tokens, which they can revoke at any time. Then you could have a mobile client use a bearer token to retrieve the feed without exposing the full read-write credential set.