Shard long passwords on Windows

[thijs-nijhuis]

Resolves #563

Description

When using the oAuth U2M flow on a windows laptop, the credentials are not stored in the Windows Credential Store because it exceed 1280 characters. Therefore, each call to Databricks results in a new authentication request (and opens a new tab in your browser). In this PR, all interaction with keyring (get, set and delete) is redirect to a custom function that will check the length and platform before storing the credentials. If on Windows and credentials are longer then 1280 characters, it will shard the password in chunk of 1280 and store those along with some meta data. When getting or deleting the credentials, it will check for this metadata and, if so fetch all shards and return the concatenated result or delete them all in case of a delete.

I have tested my code on a windows laptop as well as on a mac. On the mac, I first got the credentials with the current version in 1.7.8 so that it is stored, then replaced connections.py with the new version and ran a 'dbt debug' again to see if the stored credentials was fetched an used. It was.
I have added 2 Unit Tests to test both storing a long and a short password. All Unit Test succeeded.
I tried running the integration test but couldn't get them to run. The tox command seems to not like the bash commands on a windows laptop and running the python command directly causes all integration to fail on not finding the 'test' profile.

Checklist

• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have updated the CHANGELOG.md and added information about my change to the "dbt-databricks next" section.

[benc-db]

It may take me a few days to get to reviewing this, but thank you for your contribution. I'll run the integration tests today.

[benc-db]

Please take a look at the unit test failure :)

[thijs-nijhuis]

Hi @benc-db , thanks for checking it!
I checked the error. Locally the UT were successful but as the actions runs on (headless??) Ubuntu it fails there. It seems to be pretty tricky to get it to work on Ubuntu or will at least require change the to workflow as well. Not sure if that is way to go.

Some options I see:

1. Simply remove the UTs. Probably the easiest.
2. Mark the UTs to skip. Don't have much experience with pytest but maybe it is possible to mark to skip when running on Ubuntu and still have them run on local dev environments?
3. I can try implementing a custom backend or use an existing one that writes to a file like this. That last one would require a new install which should ideally only be installed when running Github Actions. Not sure if we would actually be testing what we want to test in that case.

What would you prefer?

[benc-db]

I think the key thing is that, if the test doesn't pass on Ubuntu, is it not passing because we're not setting the test up correctly, is the new behavior not compatible with ubuntu, or is the change regressing something. So long as we're not in the third category, we can skip the test (@pytest.mark.skip), though ideally we would detect the OS and only skip for Ubuntu. If we're in the second category, and the test is just pointing this out, we'll also want to document the limitation.

[benc-db]

After looking at the failure again, I think if you can patch keyring to just read/write the secret to files in the test, it should work regardless of OS. Ultimately the test just needs to validate your slice and rebuild logic works, regardless of keyring implementation.

[benc-db]

After looking at the failure again, I think if you can patch keyring to just read/write the secret to files in the test, it should work regardless of OS. Ultimately the test just needs to validate your slice and rebuild logic works, regardless of keyring implementation.

And if you can't get that to work, I can update the tests myself, but might be a couple of weeks until I can get to it.

[thijs-nijhuis]

Thanks @benc-db, I will try to implement the patch option than. Thanks for the feedback.

[thijs-nijhuis]

Hi @benc-db, I think the issue is solved now. I created the Mock Keyring Backend class that will write to files in a temp directory (copied some a bit of the logic from the integration test). Also expanded the UT a bit by also testing if the delete cleans-up the password properly.
The UT now succeeds on the GitHub action (when I trigger it from my repo) as well as on my laptop.

[benc-db]

Looks good, I'm going to add a changelog entry and merge.

[benc-db]

Closing in favor of #599 (moved to this fork and added Changelog). Thanks @thijs-nijhuis-shell!