ncrashed / servant-auth-token-api

Servant based API for token based authorisation

servant-auth-token-api

The package provides abstract RESTful API for token based authorisation using servant. It contains only generic types and servant-swagger instances. You may be interested in server/client side implementations:

• servant-auth-token - server side implementation using SQL subdomain of persistent.

• servant-auth-token-client (not yet published) - client side implementation using GHCJS and reflex-dom

Also you can explore swagger documentation for the API and view markdown version of docs.

servant-auth-token-api's Issues

How should signup flow look from the client side?

Hi. I wanted to use this lib in my web app written in servant.

Everything seems straightforward, but I have trouble implementing client side flow for first sign-up of new user. In order to call POST AuthSignupMethod, current api requires me to already have a token for user with registerPerm. So how this unregistered user is supposed to obtain such token? Should every anonymous user be logged on the start of application as some kind of special account that has only permission to use public APIs and register new users?

Is it a bad practice to build an endpoint that simply allows anyone to register, without the need for any kind of token?

Should AuthSigninMethod use Post?

Currently, there is:

type AuthSigninMethod 
    = "auth" :> "signin" 
        :> QueryParam "login" Login 
        :> QueryParam "password" Password 
        :> QueryParam "expire" Seconds
        :> Get '[JSON] (OnlyField "token" SimpleToken)

However, this means that any parameters will appear in the resulting URL. As such, they can appear in server logs, etc.

If, however, Post is used (as is the case with AuthSigninPostCodeMethod) then these parameters will not appear in logs, usernames and passwords can be longer, and if for some reason someone tries to call one in a browser then credentials won't be found in the history and the call won't be cached.

As another point, Get is typically used for idempotent requests, whereas each time you sign in you should expect a new token; as such, from a conceptual point of view I don't think it aligns well anyway.