Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetUser check required for jwt auth in files mode #339

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

december1981
Copy link

We need to run a check that the user validates with the passwd in JWT token or jwt authentication in files mode is unusable if GetUser returns a hard false.

This mode doesn't support any further checks on the user (as commented in the code and README - requiring the ACL list to effectively do this) so this change does not regress or modify any behaviour according to the current spec, as far as I can tell.

Copy link
Owner

@iegomez iegomez left a comment

Choose a reason for hiding this comment

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

The idea makes sense, but please add tests for it.

@@ -36,7 +36,8 @@ func NewFilesJWTChecker(authOpts map[string]string, logLevel log.Level, hasher h
}

func (o *filesJWTChecker) GetUser(token string) (bool, error) {
return false, nil
_, err := getUsernameForToken(o.options, token, o.options.skipUserExpiration)
Copy link
Owner

Choose a reason for hiding this comment

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

If there's an actual error maybe we should return it?

Copy link
Author

@december1981 december1981 Sep 28, 2024

Choose a reason for hiding this comment

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

I tried that somewhat naively - but discovered if this propagates an error by returning it, it causes a general failure in the plugin and unresponsive behaviour. As far as I can tell, getUsernameForToken returning an error just means an invalid user, for whatever reason, not a general/unexpected failure, so returning err == nil, nil seemed to be the most fitting return format.

Copy link
Owner

Choose a reason for hiding this comment

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

Oh, ok, I'll take a deeper look into then, thanks.

@december1981
Copy link
Author

The idea makes sense, but please add tests for it.

Will do

@december1981
Copy link
Author

I've added some tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants