Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Basic auth middleware #103
Basic auth middleware #103
Changes from 4 commits
e31fb1c
4c87a89
29dc037
85e2c5d
f83940e
bc5fe6a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason for passing
enable_auth()
in as a function here?Seems like we could either
Make
enable_auth
a boolean param and call it when we add the middleware i.e:Middleware(BasicAuthMiddleware, enable_auth=enable_auth())
or
Remove the
enable_auth
param and just inspect the env vars inBasicAuthMiddleware.__init__
i.e:which is basically what we're doing in the equivalent middleware in dc_django_utils
https://github.com/DemocracyClub/dc_django_utils/blob/78b20cf5e955c2994f49fd3d5db3fdad8ee5beba/dc_utils/middleware.py#L8-L15
Personally I'd find one or other of those two options clearer. The callable seems like a layer of indirection we don't really need.
The first one (boolean param) is probably easier as it would require fewer changes to the tests in
tests/test_middleware.py
as you can just replacemock_auth_enabled()
andmock_auth_disabled()
withTrue
andFalse
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had originally written in the first way you've proposed as a boolean param, but after discussion with Sym I changed it to callable. I'm not sure if I'll be able to articulate the reasoning clearly, but I'll try.
It had to do with when enable_auth() is resolved. When it's passed as a boolean, the function is resolving when settings.py is imported and passing its return value then. I think the issue with that is, when that import happens, the DC_ENVIRONMENT variable is not set yet so the function doesn't detect the environment properly.
Passing it as a callable means that it will be called each time the middleware is checking for auth which means it should have access to the env variable. I think I'm making a mistake, maybe @symroe can clarify?
I do think that 2nd proposal addresses the same issue and is maybe a better approach, though.