step to support HTTP Basic Auth #145
Conversation
| @@ -12,6 +13,10 @@ | |||
| add_header(header, value) | |||
| end | |||
|
|
|||
| When(/^the request auth basic header `([^`]*)` is assigned `([^`]*)`$/) do |header, value| | |||
There was a problem hiding this comment.
if doing basic auth then the arguments should be the username and password. The phrasing of the step should be considered relative to other steps...this step in particular is very confusing since auth is in the step but the header is an argument so the step could read very different than what is being done.
A better alternative may be something like:
When the request credentials are set for basic auth user `$user` and password `$password`
This also needs be accompanied by appropriate documentation and specification updates.
| @@ -12,6 +13,10 @@ | |||
| add_header(header, value) | |||
| end | |||
|
|
|||
| When (/^the request credentials are set for basic auth user `([^`]*)` and password `([^`]*)`$/) do |user, password| | |||
| add_header('Authorization', 'Basic ' + Base64.strict_encode64(user + ':' + password)) | |||
There was a problem hiding this comment.
Prefer string interpolation over concatenation. It's likely worth splitting this into two lines where the encoded value is assigned to a temporary value.
|
I'm going to vote for closing this since there isn't any development on this. The issue is still open. |
|
Up for me picking this up and writing tests? |
|
@Lewiscowles1986 Sure, that would be great, thanks! Sorry for the late reply, this got slightly buried in my inbox. As part of the initial PR it should likely have an entry in the Step Reference and appropriate specs. An article is planned/desired for more in-depth info for authentication pieces. |
|
Yeah I got a bit lost in the specs using quoted strings. |
|
Interesting issue. I think it probably makes sense to shuffle the way the specs are executed around. The current approach of having one spec file which defines another one to run was I think borrowed from the Cucumber project, but the main files end up as mostly boilerplate. It probably makes more sense to change the way the tests are run so that the specs can just be what are currently the inner files which are all expected to pass. This should be a lot cleaner and will also likely make it easier to make the specs portable (rather than relying on or recreating potentially Ruby specific libraries like Aruba). I'll see about swapping that over in the next day or so. |
No description provided.