Very cool! Seems a lot prettier than the basic auth prompt. It could also include a note that explains to new users where to get their API Token, and the purpose behind this thing (ie it's for vals you fork to look at your own data)
Question - can we do it without the AUTH_SECRET_KEY environment variable to sign the token? I'd like to skip that step if possible. Here are a couple suggestions:
You could generate it and store it in blob storage or as a val via @std/set
Could you use the user's Val Town API token itself (in env variables already) to sign the token?
Nice! I think private might be a restricted keyword though – how about api_token_auth for the name?
I love the idea of making the password configurable. How about the "valtown" token is the default, so you don't have to pass anything, but you can if you want? I also like the idea of the password optionally accepting a list of passwords, but we can do that later maybe if folks ask for it.
Very cool! Seems a lot prettier than the basic auth prompt. It could also include a note that explains to new users where to get their API Token, and the purpose behind this thing (ie it's for vals you fork to look at your own data)
Question - can we do it without the
AUTH_SECRET_KEY
environment variable to sign the token? I'd like to skip that step if possible. Here are a couple suggestions:I like the idea of using the api token to sign the key.
What do you think of this api:
It would allow to use different password for differents vals, or share it in multiple ones.
Nice! I think
private
might be a restricted keyword though – how aboutapi_token_auth
for the name?I love the idea of making the password configurable. How about the "valtown" token is the default, so you don't have to pass anything, but you can if you want? I also like the idea of the password optionally accepting a list of passwords, but we can do that later maybe if folks ask for it.
Sounds good to me. I'm not sure jwt is the right method for this usecase, as you normally need a user id to put in the payload.
I think sessions might be a better/simpler approach here.