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

add support for client SSL certificate and key #197

Merged
merged 6 commits into from Feb 12, 2014
Merged

add support for client SSL certificate and key #197

merged 6 commits into from Feb 12, 2014

Conversation

matleh
Copy link

@matleh matleh commented Jan 28, 2014

Added two parameters --ssl-cert and --ssl-key which allow to pass through the client side SSL certificate and key to requests.

Not sure how to test this with unittests.

Maybe naming of the parameters can be improved?

This file may either contain both private key and certificate or you may
specify --ssl-key separately.

"""
Copy link
Member

Choose a reason for hiding this comment

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

It would be good to specify also type=FileType() so that it fails with a user-friendly error message when the file does not exist or is not readable.

@jkbrzt jkbrzt closed this Jan 28, 2014
@jkbrzt jkbrzt reopened this Jan 28, 2014
@matleh
Copy link
Author

matleh commented Jan 29, 2014

@jkbr thanks for your suggestions. I modified my changes. Instead of using FileType from argparse, I wrote a little existing_file function, which produces nicer output in case of an error.

Not sure, if utils is the right place for existing_function or if you would rather have it in cli since it is only used there.

@@ -44,3 +45,12 @@ def humanize_bytes(n, precision=2):
break

return '%.*f %s' % (precision, n / factor, suffix)


def existing_file(filename):
Copy link
Member

Choose a reason for hiding this comment

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

Maybe readable_file_arg would be a better name? (It has to both exist and be readable by the current user, and also it's tied to argparse .)

As for the location, I think httpie.input would be a good place.

@matleh
Copy link
Author

matleh commented Jan 29, 2014

@jkbr Thanks again for your review. I made adjustments according to your feedback.

@jkbrzt
Copy link
Member

jkbrzt commented Feb 5, 2014

Great, thanks!

Would you mind documenting it under HTTPS in the README please?

Relevant part of python-requests docs for inspiration: http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification

As for the naming, yeah maybe it could be improved.

@matleh
Copy link
Author

matleh commented Feb 5, 2014

@jkbr would you like --cert and --privkey better as parameter names? --cert would be in line with requests parameter names but maybe it is not so clear that this is about SSL connections. Or maybe --cert and --certkey to make the connection clearer? What do you think?

@matleh
Copy link
Author

matleh commented Feb 5, 2014

I just went ahead and renamed the parameters to --cert and --certkey since I found these the most concise and in line with the requests library. Also added documentation.

@jkbrzt
Copy link
Member

jkbrzt commented Feb 5, 2014

Thanks @matleh! Let's go with these names for now. It can be renamed if we can think of anything better.

Could you also update CHANGELOG and add yourself to AUTHORS? Also, if you added just a couple of tests, that would be awesome :)

@matleh
Copy link
Author

matleh commented Feb 12, 2014

I updated CHANGELOG and AUTHORS. Adding tests is not so trivial. Have to find a way to test SSL.

@jkbrzt
Copy link
Member

jkbrzt commented Feb 12, 2014

Thanks @matleh!

jkbrzt added a commit that referenced this pull request Feb 12, 2014
add support for client SSL certificate and key
@jkbrzt jkbrzt merged commit 2c885b0 into httpie:master Feb 12, 2014
@jkbrzt
Copy link
Member

jkbrzt commented Feb 12, 2014

As for the tests, it's not necessary to test the actual SSL functionality. Testing of the handling of the arguments will do. I'll look into that.

@matleh
Copy link
Author

matleh commented Feb 13, 2014

If you mean it would be sufficent to mock out requests and check that it is called the right way - I think, I can do that. Just let me know.

@jkbrzt
Copy link
Member

jkbrzt commented Feb 13, 2014

@matleh Yep, something like that would do the trick. Thanks!

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

2 participants