Skip to content
This repository was archived by the owner on Oct 19, 2024. It is now read-only.

Conversation

@triphora
Copy link
Member

image
Not bothering to blur any of the sensitive data out because it's a local DB.

This was a PITA to figure out and test, but it seems to work as expected locally.

Comment on lines +193 to +207
Some(("Basic", token)) => {
let decoded = base64::engine::general_purpose::STANDARD
.decode(token.trim())
.map_err(|_| AuthenticationError::InvalidCredentials)?;

let credentials: String =
String::from_utf8(decoded).map_err(|_| AuthenticationError::InvalidCredentials)?;

Ok(credentials
.split_once(':')
.ok_or_else(|| AuthenticationError::InvalidCredentials)?
.1
.trim()
.to_string())
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's kind of awkward and unexpected to have the client_id be in the request payload, and the secret extracted from the Basic authentication header. Having any of these be in the request body is not recommended as per the standard.

This would work for my generic implementation (since they're sent in both ways for compatibility reasons), but a client might expect to only send them through Basic authorization, or only through the HTTP payload.

I know it adds some complexity to the authentication routine, that's the blessing of standards that are 14 years old! 😇 My intuition would be to change the signature to output an enum, so a variant can hold 2 strings and pass them along to oauth checks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants