| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Previously the kvsep before and after the kvpairs would have been
included in kvpairs, which is incorrect but should be harmless.
|
| | |
|
| | |
|
| |
|
|
| |
Partly copied from util.sasl.scram and then reduced a bit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
RFC 6120 states that
> If the initiating entity does not wish to act on behalf of another
> entity, it MUST NOT provide an authorization identity.
Thus it seems weird to require it here. We can instead expect an
username from the token data passed back from the profile.
This follows the practice of util.sasl.external where the profile
callback returns the selected username, making the authentication module
responsible for extracting the username from the token.
|
| | |
|
| |
|
|
|
|
| |
This allows token-aware things to access extra information about the
authentication, such as when the token is due to expire and the attached
custom 'data'.
|
| |
|
|
|
|
| |
E.g. if you were to just pass "username" without @hostname, the split
will return nil, "username" and the nil gets passed to saslprep() and it
does not like that.
|
| |
|
