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

added netrc support #177

Merged
merged 1 commit into from
Aug 1, 2019
Merged

added netrc support #177

merged 1 commit into from
Aug 1, 2019

Conversation

cansarigol
Copy link
Contributor

No description provided.

@cansarigol cansarigol mentioned this pull request Jul 30, 2019
httpx/config.py Outdated
@@ -39,9 +39,16 @@ class SSLConfig:
SSL Configuration.
"""

def __init__(self, *, cert: CertTypes = None, verify: VerifyTypes = True):
def __init__(
Copy link
Contributor

@sethmlarson sethmlarson Jul 30, 2019

Choose a reason for hiding this comment

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

Let's revert usages of trust_env for SSLConfig. The default behavior in the future should be use system trust stores unless we're specifically told which cert bundle to use.

Although this change reminded me to create another issue for SSL_CERT_... environment variables.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right new approach for environment variables would be nice.
I reverted the last commit.

Copy link
Contributor

@sethmlarson sethmlarson left a comment

Choose a reason for hiding this comment

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

So the whole trust_env parameter is kind of a can of worms. Ian, Cory, and @nateprewitt have all dealt with it and there are large issue threads i can dig up about all the issues.

The biggest issue is basically we're going to be embedded into applications/tools that don't expose a way to control how we configure ourselves but users still need to configure us for proxies, authentication, certificates, etc. I think the best way to achieve that is still environment variables but then you get into priorities like "both REQUESTS_CA_CERT and SSL_CERT_FILE ste defined and are different, what do we do?"

We need answers to these questions for sure, maybe a variable that can control order?

Copy link
Member

@tomchristie tomchristie left a comment

Choose a reason for hiding this comment

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

Looks really good yeah! 👍
Feel questions and comments for ya.

httpx/utils.py Outdated
@@ -64,3 +66,12 @@ def guess_json_utf(data: bytes) -> typing.Optional[str]:
return "utf-32-le"
# Did not detect a valid UTF-32 ascii-range character
return None


def get_netrc_login(url: str) -> typing.Union[typing.Tuple[str, str, str], None]:
Copy link
Member

Choose a reason for hiding this comment

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

Signature should either be host or authority here, right?
It's not clear to me from a glance at the netrc docs, which of those two is actually the correct thing to use?
Also we should prefer typing.Optional[typing.Tuple[str, str, str]] as the return annotation.

Copy link
Contributor Author

@cansarigol cansarigol Jul 31, 2019

Choose a reason for hiding this comment

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

machine in the config. I changed it as host I can change again if necessary

httpx/utils.py Outdated

def get_netrc_login(url: str) -> typing.Union[typing.Tuple[str, str, str], None]:
try:
_netrc = netrc.netrc(os.environ.get("DEFAULT_NETRC_PATH")) # type: ignore
Copy link
Member

Choose a reason for hiding this comment

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

I'd probably prefer a variable name that's not underscore prefixed here. netrc_info maybe?

Copy link
Member

Choose a reason for hiding this comment

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

Is DEFAULT_NETRC_PATH a standardized thing? (Or used by requests or something?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made it up to explain the initial path.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm pretty sure NETRC is the env variable to specify the path

tests/.netrc Outdated
@@ -0,0 +1,3 @@
machine test_entrc.httpx.com
Copy link
Member

Choose a reason for hiding this comment

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

Let's use the example.org domain, since it's there for this sort of thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If appropriate, I used netrcexample.org. Because some tests are affected by example.org.

tests/.netrc Outdated
@@ -0,0 +1,3 @@
machine test_entrc.httpx.com
login tomchristie
password password123
Copy link
Member

Choose a reason for hiding this comment

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

I'd probably marginally prefer that we use a fake style username here example-username and example-password or something. Just feels marginally cleaner.

@cansarigol
Copy link
Contributor Author

Thanks, I applied your comments.

cansarigol pushed a commit to cansarigol/httpx that referenced this pull request Jul 31, 2019
@@ -67,3 +68,27 @@ def auth(request):

assert response.status_code == 200
assert response.json() == {"auth": "Token 123"}


def test_entrc_auth():
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo: entrc -> netrc

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, fixed

Copy link
Contributor

@sethmlarson sethmlarson left a comment

Choose a reason for hiding this comment

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

I've got no issue with this current implementation.

@tomchristie tomchristie merged commit 919e8d3 into encode:master Aug 1, 2019
@tomchristie
Copy link
Member

Great stuff, thanks!
Opening up two other issues that would act as further enhancements to this.

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.

4 participants