anchor.diff:  Authorization: Token 45c1f5e3f05d0
   ----
   
  -The `authfn` should return something that will be associated to the `:identity` key in the request.
  -
  -Is the responsability of the library user to build tokens, handle its storage and verification
  -process. _buddy-auth_ only offers a lightweight layer over http for parsing and mark requests
  -as authenticated.
  +The `authfn` should return something that will be associated to the `:identity` key in
  +the request.
  +
  +Is the responsability of the library user to build tokens, handle its storage and
  +verification process. _buddy-auth_ only offers a lightweight layer over http for parsing
  +and mark requests as authenticated.
   
   You can see a complete example of using this backend <<example-token,here>>.
   
   
  -=== JWS Token (Stateless)
  -
  -Is a backend that uses signed and self contained tokens for authenticate the user. It behaves very
  -similar to the _Token_ backend (previously explained) with difference that this one does not need
  -additional user defined logic for validate tokens, because as we said previously, are self contained.
  -
  -This type of tokens enables a complete stateless authentication because the server does not need any
  -more store the token and related information, the token will contain that information.
  +=== JWS Token
  +
  +Is a backend that uses signed and self contained tokens for authenticate the user. It
  +behaves very similar to the _Token_ backend (previously explained) with difference that
  +this one does not need additional user defined logic for validate tokens, because as we
  +said previously, are self contained.
  +
  +This type of tokens enables a complete stateless authentication because the server does
  +not need any more store the token and related information, the token will contain that
  +information.
   
   Let see an demostrative example:
   
  
positive.code:     (response "Hello Anonymous")))
  ----
  
  The `authenticated?` function is a polymorphic function that receives a request and returns `true`
  in case is already authenticated by one of _buddy-auth_ backends or `false` in case contrary.
  
  Later, http-basic authentication backend requires a function with the responsibility of identify the
  incoming request. Let see how we can do it:
  
  [source, clojure]
  ----
  
negative.code:   :handler {:and [authenticated-user admin-user]}}]
  ----
  
  Additionally, if you are using *clout* based syntax for matching access rules, the
  request in a rule handler will contain `:match-params` with clout matched uri params.
  
  
  ==== Usage
  
  Now, knowing how access rules and rule handlers can be defined, it is time to see how we
  can use it in our ring applications.
  
  _buddy-auth_ exposes two ways to do it:
  
  * Using a _wrap-access-rules_ middleware.
  * Using a _restrict_ decorator for assigning specific rules handlers to concrete ring
    handler.
  
  Here are couple of examples of how we could do it:
  
  