Trailing '==' in a token breaks verify_token()

[lordslair]

Hello,

As far as I could test it, it seems that using HTTPTokenAuth with a custom scheme doesn't support having the string '==' at the end of a token

I know it's not an usual token format, so here some exemples: N2RmYmWmNDY1Nw== is not recognized in the verify_token(token) though N2RmYmWmNDY1Nw= OK N2RmYm==WmNDY1Nw OK

I'm not sure it's a bug, or if it works as intended and the token of a legacy app I use shouldn't be formed like that But I wanted to raise the issue, just in case that's a not wanted behaviour

And to give more details, these kind of tokens N2RmYmWmNDY1Nw== were perfectly recognized in previous versions (up to ~4.3.0 I'd say)

It's reproductible using your documentation and my exemple 'faulty' token: https://flask-httpauth.readthedocs.io/en/latest/#token-authentication-example Inside this block, the variable token is None

@auth.verify_token
def verify_token(token):
    if token in tokens:
        return tokens[token]

Thanks in advance

[miguelgrinberg]

Flask-HTTPAuth does not parse authentication, Flask does (or actually, Werkzeug). If your token isn't recognized, it is because Werkzeug decided the Authorization header that your client is sending is invalid.

The parser for the Authorization header has changed in recent versions of Werkzeug, and it is stricter than before. Some invalid formats for this header were allowed before, but they are rejected now. I suggest you review the header that your client is sending, and if you are sure it is correct, try it with different versions of Werkzeug and report your findings to the Flask team.

[lordslair]

Thank you very much for the fast answer. At least now I know who parses what, and what component decides if a header is invalid

If Werkzeug decided to be stricter, that's probably for good reasons So, for the specific point I wrote my issue, it's on my end to fix as it's a weird token format (I agree)

I'll see if I can modify internally the way the tokens are created to converge towards a correct/standard format And that way avoid having the same kind of troubles in a couple of years

Again, thank you for your time. L

[miguelgrinberg]

@lordslair The == are not weird, they are actually pretty common in Basic authentication (but not for tokens). They are padding for the base64 encoding of the username and password. This is why I asked you to check your client. If your client is sending a Basic auth header, then it should send properly encoded base64 credentials. If your client is sending a Bearer auth header, then it could send anything it wants as a token, including one that ends with ==. If this fails to parse, it is a Werkzeug bug.