matrix-client-haskell
matrix-client-haskell copied to clipboard
softwarefactory-project
expose auth token in ClientSession?
I want to use the login function to generate auth tokens for later use in a bot. I wrote login to return a ClientSession so that passwords can be used as an alternative to an auth token when starting a session (such as if the lib were to be used for build a user facing app rather then a bot).
I think both use cases are totally valid. How would you feel about adding a function to extract just the auth token from a ClientSession?
How about adding a loginToken :: LoginCredentials -> MatrixIO (ClientSession, MatrixToken) instead, and make the current login be fst <$> loginToken cred ? Or perhaps we could simply change the current function. Also I noticed login is failing on error, and perhaps it would be better to make it return a MatrixIO with the error in Left?
If that does not work, then sure, I don't mind adding an accessor for the token.
We might also want to add a loginCacheToken helper that would copy the token in ~/.cache/haskell-matrix-client/token and re-use it on subsequent call to avoid leaking access tokens. That might be a better solution, and perhaps that should be the default behavior of the login function.
Oh these are all great suggestions. I'll put together a PR this week. I'm not sure why I didn't put login in MatrixIO to begin with..
so we want:
loginToken :: LoginCredentials -> MatrixIO (ClientSession, MatrixToken)for generating access tokens,loginshould returnMatrixIO- Possibly, change
loginto use a token stored in the xdg cache directory?
For 3 i would prefer login to take a path to the token on disk so that I can specify a cache folder for whatever application i am building with matrix-client.
Thank you for the feedback and the contributions, the cofree-bot looks great!
Thinking about it some more, caching the token can be tricky, how the caller would know if the login will work without credentials? Thus I would simply replace the current login with loginToken, and let the caller deal with the token.
For example, a cache aware interface could take a IO LoginCredentials action as a parameter, and it would run it if the cached token is missing or invalid. But I think that's a bit out of scope for this library...
Thank you for the feedback and the contributions, the cofree-bot looks great!
Thank you!
For example, a cache aware interface could take a
IO LoginCredentialsaction as a parameter, and it would run it if the cached token is missing or invalid. But I think that's a bit out of scope for this library...
I agree that caching is likely out of scope for the library and should be handled by downstream users.
I'll write a PR without the caching bit then we can sort it out in the PR.