add option to check allowed groups using the ldap connection of the search user #183

[tobi45]

This pull request contains two things (Sorry, I know, bad practice):

1. it adds an option to verify the membership of user being authenticated in the configured allowed_groups with the ldap connection of the search user instead of the ldap connection with the user being authenticated (default behavior) (see allowed_groups are looked up with authenticated user instead of search user #183)
2. it adds an alternative guide and configuration files to setup a development environment using docker containers and visual studio code with the remote containers extension

Please inform me if you want separate pull requests or just one for 1).

The diff for 1) should be straight forward but the diff tools struggle a bit on the method resolve_username cause they compare their changes with the added option. Eventually a parameter was added to the method and the connection establishment was moved to method authenticate.

On the test side I decided to use mock objects for the connections and verify if the correct connection is used and the correct methods are called. This test doesn't require the ldap server running.

[welcome]

Thanks for submitting your first pull request! You are awesome! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please make sure you followed the pull request template, as this will help us review your contribution more quickly.

You can meet the other Jovyans by joining our Discourse forum. There is also a intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[manics]

Hi! Please could you update this PR so it contains just the fixes for #183 ? As mentioned in that issue we're lacking people with expertise in LDAP, but by simplifying this PR it'll at least make it slightly easier for others to review.

[tobi45]

Thanks for your quick response! I totally understand, I have no expertise with LDAP as well. As far as I understand github I am not able to change the branch (of my repository) of that pull request, thus I had to revert both commits related to the 2nd point mentioned in the description above. But I think that's somehow complicates the changesets.

I just created 2 branches in my repository targeting both points in the description individually and both base on the current master of this repository. Shall I create 2 new pull requests for a leaner commit history? Or do you prefer to continue on this one?

Regarding the failed github actions: I understand the failed lint task but I have no idea why the tests are failing. That seems to be a setup problem. Locally they all succeed.

[tobi45]

I replaced this PR with #207 and close it.