Allow custom and per context authentication

[solsson]

One option would be to override the default user with a context arg like those used for body and headers.

To override for multiple specs we could add another context detection rule.

Should we continue to assume BASIC auth, or somehow try to make authentication method pluggable?

[takesson]

I am not sure how to test both basic and token auth in the future but i am quite sure we need to.

• 2 nodes executed in parallel in the same build?
• one node but 2 test executions with a small converge in between?
• 2 separate builds (2 node files)? Likely works for main branch but PR remains to be seen (perhaps need to choose which node to test in PR).

I guess this decision influences how to best configure the default auth in testbeat. Yolean would need this dual testing quite urgently?

[takesson]

One option would be to override the default user with a context arg like those used for body and headers.

Yes, I think that makes sense. Override is likely to be authtype specific anyway. Hmm, can tests be conditionally executed? Need to break out into cookbooks? cms-auth-basic vs cms-auth-token

I suggest the following context args:

• authbasicuser
• authbasicpassword
• authtoken (Bearer token)
• authcookie (if you are using that, I will likely code Bearer support into mod-oidc and assume that the cookie pieces work)

[solsson]

Design idea:

• Testbeat recognizes a NODE_AUTH environment variable.
• If set testbeat does a require or include (ruby decision) on a file with that path, absolute or relative to rspec run
• Auth file is a .rb with tree opt-in entry points:
  • before(request)
  • on401(request)
  • on404(request)
• An auth method typically sets request headers, and the two latter may trigger a re-request
• Auth file can contain multiple named auth providers. One should be named default.
• A spec context can say for example describe "authenticated as admin" where admin maps to a named auth.
• The embedded auth file has a default that runs the current BASIC testuser/testpassword

Noderunner looks in the node folder for a testbeat-auth.rb file. If such a file exists it sets the NODE_AUTH env.

[takesson]

Sounds like a good design. Do we have any way of including / excluding tests based on the type of NODE_AUTH?

Do you think we need "on40x" events? I think those things can be tested explicitly with "unauthenticated". All methods we anticipate can be handled with "before" unless we really want to test the redirect etc. I like the route forward but we might only need to implement "before" now.

[solsson]

I think we want to do basic auth only on 401, at least with the embedded
impl. That's hard to do on before, unless ruby api supports it. Let's see.

I guess we could add an interface method that can exclude given a context
description.

On Sun, Nov 29, 2015, 17:02 Thomas Åkesson notifications@github.com wrote:

Sounds like a good design. Do we have any way of including / excluding
tests based on the type of NODE_AUTH?

Do you think we need "on40x" events? I think those things can be tested
explicitly with "unauthenticated". All methods we anticipate can be handled
with "before" unless we really want to test the redirect etc. I like the
route forward but we might only need to implement "before" now.

—
Reply to this email directly or view it on GitHub
#1 (comment).