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

New LDAP Auth Method Class #244

Merged
merged 12 commits into from
Aug 7, 2018
Merged

New LDAP Auth Method Class #244

merged 12 commits into from
Aug 7, 2018

Conversation

jeffwecan
Copy link
Member

@jeffwecan jeffwecan commented Aug 6, 2018

Similar idea to #242. Adding in a new "auth" class to cover the Vault LDAP auth method's API routes.

Also related to the spirit of #95.

@jeffwecan jeffwecan requested a review from gulducat August 6, 2018 12:03
@codecov-io
Copy link

codecov-io commented Aug 6, 2018

Codecov Report

Merging #244 into master will increase coverage by 1.18%.
The diff coverage is 98.7%.

@@            Coverage Diff             @@
##           master     #244      +/-   ##
==========================================
+ Coverage   86.83%   88.02%   +1.18%     
==========================================
  Files          10       11       +1     
  Lines         904      977      +73     
==========================================
+ Hits          785      860      +75     
+ Misses        119      117       -2
Impacted Files Coverage Δ
hvac/api/auth/ldap.py 100% <100%> (ø)
hvac/api/auth/__init__.py 100% <100%> (ø) ⬆️
hvac/v1/__init__.py 85.36% <80%> (+0.31%) ⬆️

@jeffwecan jeffwecan added this to the 0.6.3 milestone Aug 6, 2018
Copy link

@gulducat gulducat left a comment

Choose a reason for hiding this comment

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

I really like the structure of the lib code itself.

The redundancy of unit vs integration tests is a bit cumbersome. The value of having both is clear, but it would be nice (and easier to maintain) if they could be consolidated somehow.

Perhaps a base class or helper(s) that either does or does not set up requests_mock based on whether we're running integration or unit tests? I'm not sure of any other codebases that may have useful patterns to follow in this regard, just thinkin out loud.

:return: Test certificate contents
:rtype: str | unicode
"""
test_data_dir = os.path.join(os.path.dirname(os.path.realpath(__file__)), '..', '..', '..', '..', '..', 'test')
Copy link

Choose a reason for hiding this comment

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

These '..'s smell funny - a helper method somewhere (hvac/tests/utils.py? or a new hvac/tests/test_files.py?) would be nice.

from hvac.tests import test_files
test_cert = test_files.get_file_contents('server-cert.pem')

get_file_contents(name) could call a get_filename(name) that joins with a get_base_dir().
removes some boilerplate, and later if test files are moved around, would only need to update get_base_dir().

Copy link
Member Author

Choose a reason for hiding this comment

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

@dbwpe: Does 79fc92c cover what you had in mind?

Copy link
Member Author

Choose a reason for hiding this comment

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

Then I read your actual comment and bc57308 is closer to the mark...

if policies is None:
policies = []
params = {
'policies': ','.join(policies),
Copy link

Choose a reason for hiding this comment

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

I always ask myself in cases like this whether I want to enforce input types, or just say "rtfds" (read the frickin docstring). this kind of thing has bitten me in the past:

In [1]: policies = 'only-one-policy'

In [2]: ','.join(policies)
Out[2]: 'o,n,l,y,-,o,n,e,-,p,o,l,i,c,y'

If a bunk input type can result in Quite Bad Things, then I'll enforce the type (either with an exception, or help em out and make it a list), otherwise if the API (or whatever) handles it gracefully, just let the chips fall where they may.

Copy link
Member Author

Choose a reason for hiding this comment

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

I added a ParamValidation exception a while back for this type of deal, would be reasonable to utilize it here. Could also make the case for casting things to a list if given a string where a list is expected, but I think its better to alert the user to the correct param type rather than hide it away implicitly...

Copy link
Member Author

Choose a reason for hiding this comment

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

6210eeb. Touches on #129 to an extent.

Copy link

@gulducat gulducat left a comment

Choose a reason for hiding this comment

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

🔐 👍

@jeffwecan jeffwecan merged commit 41c2bb9 into hvac:master Aug 7, 2018
@jeffwecan jeffwecan deleted the new_ldap_class branch August 7, 2018 22:24
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.

3 participants