Make ERP5TypeTestCase.publish() usable in live tests

A change that also applies to traditional tests is that the password does not
need to be known when logging with basic authentication. If the given password
is empty (e.g. 'ERP5TypeTestCase:'), password validation passes regardless the
actual password: to keep things secure, this exception is only valid for the
test thread and during the call to publish(). This is a simple way to deal with
random passwords in live tests.

product/ERP5Type/tests/ERP5TypeLiveTestCase.py

@@ -170,6 +170,15 @@ class ERP5TypeLiveTestCase(ERP5TypeTestCaseMixin):
       '''
       pass
 
+    def publish(self, *args, **kw):
+      from zope.security.management import thread_local
+      interaction = thread_local.interaction
+      try:
+        del thread_local.interaction
+        return super(ERP5TypeLiveTestCase, self).publish(*args, **kw)
+      finally:
+        thread_local.interaction = interaction
+
 from Products.ERP5Type.dynamic.component_package import ComponentDynamicPackage
 from Products.ERP5Type.tests.runUnitTest import ERP5TypeTestLoader
 

product/ERP5Type/tests/ERP5TypeTestCase.py

@@ -718,7 +718,15 @@ class ERP5TypeTestCaseMixin(ProcessingNodeTestCase, PortalTestCase):
             raise TypeError, ''
 
         if basic:
-            env['HTTP_AUTHORIZATION'] = "Basic %s" % base64.encodestring(basic).replace('\012', '')
+          env['HTTP_AUTHORIZATION'] = "Basic %s" % \
+            base64.encodestring(basic).replace('\n', '')
+          from AccessControl import AuthEncoding
+          from thread import get_ident
+          me = get_ident()
+          orig_pw_validate = AuthEncoding.pw_validate
+          def pw_validate(reference, password):
+            return (me == get_ident() and not password
+                    or pw_validate(reference, password))
 
         if stdin is None:
             stdin = StringIO()
@@ -726,16 +734,21 @@ class ERP5TypeTestCaseMixin(ProcessingNodeTestCase, PortalTestCase):
         outstream = StringIO()
         response = Response(stdout=outstream, stderr=sys.stderr)
 
-        publish_module('Zope2',
-                       response=response,
-                       stdin=stdin,
-                       environ=env,
-                       extra=extra,
-                       debug=not handle_errors,
-                      )
-
-        # Restore security manager
-        setSecurityManager(sm)
+        try:
+          if basic:
+            AuthEncoding.pw_validate = pw_validate
+          publish_module('Zope2',
+                         response=response,
+                         stdin=stdin,
+                         environ=env,
+                         extra=extra,
+                         debug=not handle_errors,
+                        )
+        finally:
+          if basic:
+            AuthEncoding.pw_validate = orig_pw_validate
+          # Restore security manager
+          setSecurityManager(sm)
 
         # Make sure that the skin cache does not have objects that were
         # loaded with the connection used by the requested url.

[Georgios Dagkakis]

I am getting

RuntimeError: maximum recursion depth exceeded while calling a Python object

In some tests of my branch. Which comes from here. Looking at the code, I would expect the it would be

or orig_pw_validate(reference, password))

yet tests pass on master, so I may be wrong. But isn't the logic here:

• If the password is empty and it is the test thread running, then return true (dummy authentication for tests)
• Otherwise (no test thread, or test has an actual password), use actual authentication of AccessControl

or I miss it?

[Julien Muchembled]

oops, of course it should be orig_pw_validate(reference, password))

But it's not the only issue with this commit. There exist several tests checking that authentication fails when a empty password is passed for a user that has a non-empty password. I am working on it.

[Georgios Dagkakis]

OK, thanks, please update once fixed so I rebase.

(I still do not get why tests did not fail on master myself, but I suppose it will come within your fix work.)

[Jérome Perrin]

This patch seems to fix #20161018-1754D96

/cc @arnau