Horizon: Expose token generation

[stellanhaglund]

It would be really great if I would be able to generate jwt tokens for my users when using horizon as a package to my server.

[danielmewes]

You can run hz make-token to manually create a token for a user. We just added this feature, so it's still undocumented and a bit immature. The generated tokens are also only valid for one day right now.

[stellanhaglund]

I have horizon as a package to my server and i need to write some custom
auth since there is none right now, so i wont be able to run hz commands, i
need to be able to generate a token if the user is allowed to get one.

tisdag 17 maj 2016 skrev Daniel Mewes [email protected]:

You can run hz make-token to manually create a token for a user. We just
added this feature, so it's still undocumented and a bit immature. The
generated tokens are also only valid for one day right now.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/rethinkdb/horizon/issues/398#issuecomment-219820819

[deontologician]

Ok, so we should expose token generation in the horizon library explicitly. This seems simple, any comments @Tryneus ?

[marshall007]

In #419 this would be:

horizon._auth.generate(<provider>, <identifier>) // -> Promise<string>

Where provider is a string representing the provider name (ex. twitter) and identifier is any value (string, array, object, etc) that uniquely identifies the user for that provider (ex. twitter username).

You could also use the lower-level JWT APIs; however, doing so won't automatically create users in the internal horizon_internal.users and horizon_internal.auth_users tables for you.

horizon._auth._jwt.sign(<payload>) // -> string
horizon._auth._jwt.verify(<token>) // -> Promise<object>

@deontologician @Tryneus in this case, we could just expose these methods in a less scary way, but I think the real solution is a proper API for attaching auth providers to the server. Either way, we should probably start discussing the overall vision for the public server API before things just get tacked on (see #345).

[deontologician]

I think this is going to be part of the server refactor for plugins/middleware.