Added HTTP authentication to the API.

[ot2789]

• Now the requests to HTTP can also contain Basic, Digest and Proxy
  authentication.

[asimell]

Instead of having four basically identical keywords, would it be more reasonable to have a single keyword Set Client Authentication that takes the type of authentication as an argument and handle passing it on in the keyword itself?
E.g

Set Client Authentication | basic | username | password
Set Client Authentication | digest | username | password
Set Client Authentication | | | 

[ot2789]

Instead of having four basically identical keywords, would it be more reasonable to have a single keyword Set Client Authentication that takes the type of authentication as an argument and handle passing it on in the keyword itself?
E.g

Set Client Authentication | basic | username | password
Set Client Authentication | digest | username | password
Set Client Authentication | | | 

Yes. I can do that it is not a problem. Two questions however.

1. Is it fine if the first parameter is a string and the check is done through string comparison (case insensitive).
2. In the situation in which a user wants to clear the authentication. Would the value ${NONE} be used or can the user call this keyword without any arguments?

In the code I also replaced deepcopy with copy because if the user adds the Digest authentication the deepcopy function cannot get the treading local structurest that are used in HTTPDigestAuth. I don't know if this is the best solution to this problem.

[asimell]

1. I think case insensitive string comparison should work just fine as long as the supported values are documented.
2. Using ${NONE} would probably make more sense than no arguments at all. This would mean that the first argument is mandatory (type of authentication) and the username and password are optional.

[ot2789]

I updated the keywords according to your comment. Let me know if you have other ideas.

[asimell]

Could you also create tests to test the new functionality? Place the tests in the atest directory. Also, by looking at headers.robot it looks like the behaviour of this keyword is already somewhat supported just by using headers.

Could you also open this PR to eficode/restinstance? While we're waiting for repository transfer (ping @asyrjasalo) we're handling PRs by first merging them to Eficode fork and then creating a combined PR here with the next release.

[ot2789]

It is true that headers.robot can fix the Basic authentication. But it doesn't fix the Digest which is dynamic on connection.
I will add the test then continue with the PR on the other repository after you confirm here that we're good here.

[asimell]

Found some spots that could be cleaned. Otherwise looks good.

[asimell]

@ot2789 LGTM. Can you create a PR to Eficode/RESTinstance (I'll keep this one open as well). We'll merge this first there and then come back here with full release candidate.

[ot2789]

@asimell Ok. I'll create a PR there as well. Can you tell if there is a way to install the release that contains this PR through pip3?
Edit: Done, eficode#8

[asimell]

@ot2789 We will make a separate PR here that we'll merge here and release that to PyPI. We won't make the release through Eficode fork. Unfortunately, @asyrjasalo hasn't transferred this repo to Eficode org, even though he asked us to maintain this library. We've got our CI in place and full access rights in Eficode org, so this is how we roll for now.

[ot2789]

@asimell It is ok. I don't need to use the Eficode fork for updating. Just interested in installing it with pip3. So when this is approved, checked and merged. Let me know how I can install it. I expect to be something like pip3 install RESTinstance==1.x.xrc1 or something among those lines.

[github-actions]

This pull request is stale because it has been open for 30 days with no activity.

[asyrjasalo]

This was implemented and released. Thank you for your contribution!