TokenAuthentication: Allow custom keyword in the header

[hroncok]

This allows subclassing TokenAuthentication and setting custom keyword,
thus allowing the Authorization header to be for example:

Bearer 956e252a-513c-48c5-92dd-bfddc364e812

It doesn't change the behavior of TokenAuthentication itself,
it simply allows to reuse the logic of TokenAuthentication without
the need of copy pasting the class and changing one hardcoded string.

Related: #4080

[codecov-io]

Current coverage is 91.39%

Merging #4097 into master will increase coverage by +<.01%

@@             master      #4097   diff @@
==========================================
  Files            51         51          
  Lines          5472       5473     +1   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           5001       5002     +1   
  Misses          471        471          
  Partials          0          0          

Powered by Codecov. Last updated by 37b1ce5...c7c7726

[tomchristie]

This isn't unreasonable, but I'd still rather just have end-users customize the class if they want differing behavior.

[hroncok]

I don't understand the objection against this, so I'll try to explain my reason even further.

This is the customization I would like to be able to do (In my own code/project/app) and this pull request makes that possible:

from rest_framework import authentication


class BearerAuthentication(authentication.TokenAuthentication):
    '''
    Simple token based authentication using utvsapitoken.

    Clients should authenticate by passing the token key in the 'Authorization'
    HTTP header, prepended with the string 'Bearer '.  For example:

        Authorization: Bearer 956e252a-513c-48c5-92dd-bfddc364e812
    '''
    keyword = 'Bearer'

Unfortunately, this is what has to be done at this point (without this pull request):

from rest_framework import authentication, exceptions
from django.utils.translation import ugettext_lazy as _


class BearerAuthentication(authentication.TokenAuthentication):
    '''
    Simple token based authentication using utvsapitoken.

    Clients should authenticate by passing the token key in the 'Authorization'
    HTTP header, prepended with the string 'Bearer '.  For example:

        Authorization: Bearer 956e252a-513c-48c5-92dd-bfddc364e812
    '''
    def authenticate(self, request):
        auth = authentication.get_authorization_header(request).split()

        if not auth or auth[0].lower() != b'bearer':
            return None

        if len(auth) == 1:
            msg = _('Invalid token header. No credentials provided.')
            raise exceptions.AuthenticationFailed(msg)
        elif len(auth) > 2:
            msg = _('Invalid token header. Token string should not contain spaces.')
            raise exceptions.AuthenticationFailed(msg)

        try:
            token = auth[1].decode()
        except UnicodeError:
            msg = _('Invalid token header. Token string should not contain invalid characters.')
            raise exceptions.AuthenticationFailed(msg)

        return self.authenticate_credentials(token)

    def authenticate_header(self, request):
        return 'Bearer'

This is no customization, this is copy pasting code form Django REST framework.
This has many disadvantages, every time the code is changed in DRF (let's say for security fixes etc.), I would need to keep tack of such change and change my copy pasted code.

This PR simply allows easier customization. Would you please reconsider, or provide more verbose explanation? I'm willing to shape this PR a bit (make keyword a method, rename it, etc.). Thanks

[xordoquy]

I'd join in this request on the principle.
This change doesn't make things harder to maintain and will ease overriding the class.

[tomchristie]

I'd suggest we use the proper casing here, and instead do .lower() in the comparison against the auth header.

[hroncok]

Ok, I was considering that as well, don't have strong opinion. Will do.

[hroncok]

Fixed

[tomchristie]

Given @xordoquy's take let's reopen and have this in.

I don't understand the objection against this.

In the absence of any other factors the tendency is always for classes such as this to accumulate more and more interface. I'm generally in favor of pushing back against that with "put some code in your codebase" wherever possible.

[hroncok]

I can see. Well, I'm replacing the token validation with my own logic, so I'm definitely putting some code in my own codebase, I was simply against copy pasting the parts that should be inheritable.

[tomchristie]

👍 S'all good. Thanks @hroncok, @xordoquy, @jpocentek.

[hroncok]

Thanks @xordoquy, @tomchristie.

[xordoquy]

Thanks @tomchristie for taking the time to reconsider this and thanks @hroncok for the PR.

[jpadilla]

I'm a bit late on the conv, but I don't really think keyword is descriptive. Specs usually call this authentication scheme.

[hroncok]

Honestly, I made up the variable name. Didn't think of anything better. In this context it's a word, not a scheme. But I don't mind any other reasonable name.

[kevin-brown]

I'm a bit late on the conv, but I don't really think keyword is descriptive.

I'm going to second this sentiment.

In the HTTP spec, this is usually referred to as the "scheme" [1, 2, 3]. My only problem with using "keyword" is that it's only slightly more descriptive than "thing" or "indicator".

[hroncok]

You are quite right. Shall I craft another PR?