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

DM-21222: Stop forcing existence of credentials in connection strings. #191

Merged
merged 2 commits into from Sep 14, 2019

Conversation

DinoBektesevic
Copy link
Collaborator

Not forcing username and password in connection strings allows other mechanisms, such as Oracle Wallet, to insert the credentials.

It was difficult to untangle getAuth into sub-functionality so exists is implemented in terms of getAuth. Is that ok?

Would this work?

@DinoBektesevic DinoBektesevic self-assigned this Sep 9, 2019
@DinoBektesevic DinoBektesevic changed the title Stop forcing existence of credentials in connection strings. DM-21222: Stop forcing existence of credentials in connection strings. Sep 9, 2019
@ktlim
Copy link
Contributor

ktlim commented Sep 9, 2019

I was just thinking of removing most of the error raises, allowing username and password to be returned as empty strings (or None).

Reading through the file twice (for exists and then getAuth) seems undesirable.

Instead of parsing through the file twice with `exists` and then
`getAuth` re-write the `DbAuth.getAuth` method to allow username
and password to be None.

This requires silencing any errors when credentials are
miss-configured from ConnectionStringFactory's side. Short of
having an explicit key in config stating whether a credentials
lookup is desired there is no clear cut way to say if we must
insist that username/password must exist or not.

Instead, we believe the provided db string and try to return it
unchanged as often as possible unless everything is configured
correctly.
@DinoBektesevic
Copy link
Collaborator Author

Ok. redid it the way @ktlim wanted.

Username and password are allowed to be None. Instead of avoiding sqlite specifically, we avoid any situation where host is not specified explicitly. ConnectionStringFactory now believes the correctness of given connection string optimistically.

Copy link
Contributor

@brianv0 brianv0 left a comment

Choose a reason for hiding this comment

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

Looks fine, any PR where you end up with less LOC is usually good 👍

@DinoBektesevic
Copy link
Collaborator Author

DinoBektesevic commented Sep 12, 2019

@ktlim You are probably quite busy this week, but could you take a look and comment on the changes. Is this more like what you had in mind?

Someone should also run Jenkins on this because I don't have the privileges too.

Copy link
Member

@timj timj left a comment

Choose a reason for hiding this comment

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

Looks okay to me. I'll do a Jenkins run. I don't think we need to wait for @ktlim to also approve.

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.

None yet

4 participants