jeremyheiler / lein-paprika Goto Github PK

It should be possible to cache multiple tokens. The reason for this is because you could use Leiningen profiles to manage different accounts, or identical accounts with different scopes. In order to do this there needs to be a way to differentiate between the cached tokens, and determining which token is appropriate for the current session.

Cache invalidation should only operate on the token for the specific set of credentials being used. All other tokens should remain unaffected, except when there is a read error and the whole cache needs to be invalidated.

How should cached tokens be differentiated?

• Profile Name
  • I'm not sure how to obtain it once a profile has been merged into the project map.
  • Not unique enough for standalone usage of the plugin.
• Username and Scopes
  • This would be nice, but the information is not available until the token is obtained.
• Custom Key
  • As a last resort, the user could provide a custom key.
  • I would rather not do this because it adds more overhead.
• Client ID
  • This is one of the parameters when authorizing with Client ID and Client Secret.
  • If authorizing with a token, this value can be obtain by invoking paprika.core/token.
  • You wouldn't be able to authorize multiple accounts against the same Client ID. Although, it could be possible for the user to also provide the username of the specific account they want to use. Who would be the default user? Perhaps the username should be required then? I hate to require an extra field just for caching.

{:client-id-a {:user-1 {:access-token "user-1-token"}}
              {:user-2 {:access-token "user-2-token"}}}

With issue #1 complete, the latest token fetched from App.net will be cached. However, once a token is cached it will be used regardless if you're using different credentials. There needs to be a way to invalidate the cache and obtain a new token if the credentials are different.

If there is an error reading the cache, then it's safe to assume the file was corrupted at some point. In this case the file should be deleted and a new token should be obtained with the provided credentials.

Any endpoint in paprika.core should be executable as a subcommand.

lein paprika create-post :text "This is this post's text."

All the parameters will be bundled into a map and passed into the function. The token will be extracted from the map if it is provided by the command (ditto with client id and secret), otherwise it will be obtained by the usual methods.

Should there be an alias? Perhaps paprika or adn.

Perhaps like this?

lein paprika auth :output :json

Even though it's the default, it should support :edn as an option.

A token should be cached if it was obtained by authenticating the user. If the token was provided by the user, then it must not cache it. Any token that is provided by the user must take precedence over any cached token. Consideration must be taken into account with regard to using multiple profiles for multiple apps.

A cached token could live in the .paprika-token file from within a project, or in the ~/.lein/paprika-token file when not. A subcommand should be introduced to clear the cached token.

Should the entire user map be cached, or just the token?

It should be possible to provide an access token if you already have one.

As a command line parameter:

lein paprika repl :token $TOKEN

As a key under :paprika in the project map:

{:paprika {:token $TOKEN}}