easy way to generate authorization tokens from backend UI

[☮ elf Pavlik ☮]

Ahoy!

I cc unhosted since i don't know how many people already have joined to: remote...@librelist.com
You can do this just by sending email to list, first one will not get distributed but will just trigger subscription procedure...

Back to subject, looking at: https://5apps.com/account/settings/remotestorage
I see no button: 'Add authorization'
Which I need for apps not running in web browser :)

Any suggestions where we can add recommendation for people implementing remotestorage backends to make it easy to add new authorization and have token for copy&paste procedure :D

Cheers!

[Michiel de Jong]

i'm not sure if i'm a big fan of the copy-paste procedure, isn't that
a diversion from OAuth? Can't you achieve the same thing using OAuth2
implicit grant, and then use ajax for posting the token into your
Relying Party's server?

maybe i misunderstood your use case.

> --
>
>
>

[☮ elf Pavlik ☮]

Excerpts from Michiel de Jong's message of 2012-09-29 12:55:55 +0000:

> i'm not sure if i'm a big fan of the copy-paste procedure, isn't that
> a diversion from OAuth? Can't you achieve the same thing using OAuth2
> implicit grant, and then use ajax for posting the token into your
> Relying Party's server?
>
> maybe i misunderstood your use case.

AJAX? i talk about reading/writing to remote storage NOT from a web browser :)

for example some script dumping my emails there as niklas have made or fetching news feeds from my OMPL file etc.

[Michiel de Jong]

you can write an unhosted web app that displays the token it receives,
for you to cut and paste into your CLI. Ask James Coglan, he's working
on a CLI client as well and may be able to help you with that.

[☮ elf Pavlik ☮]

Excerpts from Michiel de Jong's message of 2012-09-29 13:53:36 +0000:

> you can write an unhosted web app that displays the token it receives,
> for you to cut and paste into your CLI. Ask James Coglan, he's working
> on a CLI client as well and may be able to help you with that.

that makes sense :)
i guess it should give me no obstacles to generate as many tokens as i want with single app without revoking them?

[Michiel de Jong]

possibly but not likely. you would probably get the same token each
time, although this decision is left up to the remotestorage server
implementation.

in any case, for consistency of the revokation it would make sense to
match one unhosted web app with each script you want to run.

But once you're in your scripting environment, you could use other
methods to "sub-license" different scripts, where only one
master-script has the token.

On Sat, Sep 29, 2012 at 4:35 PM, ☮ elf Pavlik ☮

[☮ elf Pavlik ☮]

Excerpts from Michiel de Jong's message of 2012-09-29 14:39:38 +0000:

> possibly but not likely. you would probably get the same token each
> time, although this decision is left up to the remotestorage server
> implementation.
>
> in any case, for consistency of the revokation it would make sense to
> match one unhosted web app with each script you want to run.
>
> But once you're in your scripting environment, you could use other
> methods to "sub-license" different scripts, where only one
> master-script has the token.

well then i guess just generating tokens from interface of my storage backend sounds like more straight forward approach to me :)

[Michiel de Jong]

it's not something that is (was?) supported by any of OAuth's flows,
and it seems pretty niche to me.

i don't think it would merit changing our spec and adding such a
feature to the requirements we put on remotestorage providers.

On Sat, Sep 29, 2012 at 4:49 PM, ☮ elf Pavlik ☮

[☮ elf Pavlik ☮]

Excerpts from Michiel de Jong's message of 2012-09-29 15:07:13 +0000:

> it's not something that is (was?) supported by any of OAuth's flows,
> and it seems pretty niche to me.
>
> i don't think it would merit changing our spec and adding such a
> feature to the requirements we put on remotestorage providers.

i didn't mean requirements but just recommendation bringing to attention cases when such feature comes handy... can you see how much effort it adds while you update owncloud? i also have another idea for storage features discovery which i will post more about in separate thread later on :)

[Michiel de Jong]

i would be even more opposed to making it a recommendation than to
making it a requirement. :)

unlike requirements, recommendations create a distinction between
"haves" and "have nots". i want everything to work with one canonical
version of remotestorage, and i want that one version to work with
everything. no splitting off into separate incompatible subcamps
please. :)

Find jcoglan on irc, he has also been studying this topic a lot.

[☮ elf Pavlik ☮]

Excerpts from Michiel de Jong's message of 2012-09-29 15:39:27 +0000:

> i would be even more opposed to making it a recommendation than to
> making it a requirement. :)
>
> unlike requirements, recommendations create a distinction between
> "haves" and "have nots". i want everything to work with one canonical
> version of remotestorage, and i want that one version to work with
> everything. no splitting off into separate incompatible subcamps
> please. :)
>
> Find jcoglan on irc, he has also been studying this topic a lot.

will do thx!
https://github.com/jcoglan/remotestorage-oauth