delta/python-packages/qpid-python.git/qpid/cpp/src/tests/sasl.mk, branch qpid-3346

QPID-3346: resync this development branch with latest trunk

2011-10-28T15:52:13+00:00

git-svn-id: https://svn.apache.org/repos/asf/qpid/branches/qpid-3346@1190406 13f79535-47bb-0310-9956-ffa450edef68

Add new cluster-based sasl_fed_ex tests to EXTRA-DIST

2011-03-09T14:10:45+00:00

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1079808 13f79535-47bb-0310-9956-ffa450edef68

QPID-1672

2011-03-08T20:59:26+00:00

clustered versions of the 4 federated sasl external tests.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1079539 13f79535-47bb-0310-9956-ffa450edef68

What was a single test -- sasl_fed_ex -- is now

2011-02-28T18:00:10+00:00

4 tests with a common core.  They are:

  sasl_fed_ex_dynamic
  sasl_fed_ex_link
  sasl_fed_ex_queue
  sasl_fed_ex_route 

( and the common core is sasl_fed_ex )

These tests correspond to the 4 different ways that the 
qpid-route command has of making links, or links+routes.
All those pathways have to be modified so that the new
"mechanism" argument information can be passed down and
used -- so that you can specify a SASL mechnism to be
used on the interbroker link that you create.

( So -- the qpid-route command also had to be modified
to propagate the mechanism info with all 4 subcommands. )

Since the SASL mechanism is owned by the link, these 
tests check that the link comes up and becomes operational.

Finally, I modified the sasl-mechanism flag in qpid-route
to call it "client-sasl-mechanism" to better distinguish 
between the SASL mechanism used in the created route -- and
the SASL mechanism (if any) that is used when the qpid-route 
client itself connects to the broker that it is talking to.



git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1075452 13f79535-47bb-0310-9956-ffa450edef68

Include the new sasl_fed_ex test in EXTRA_DIST.

2010-12-17T15:29:38+00:00

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1050424 13f79535-47bb-0310-9956-ffa450edef68

In broker::ConectionHandler, use the security settings, if any,

2010-12-16T21:10:38+00:00

provided by the transport layer when starting SASL.
This allows the SASL mechanism EXTERNAL to be satisfied with 
SSL transport security.
The test, sasl_fed_ex, uses this SASL/SSL security on a 
federated link between two brokers.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1050162 13f79535-47bb-0310-9956-ffa450edef68

Add a small executable that prints out the sasl version number in integer form.

2010-10-28T04:39:43+00:00

Use it in the sasl_fed test to determine whether that test can run.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1028180 13f79535-47bb-0310-9956-ffa450edef68

Fix make distcheck error: added sasl_fed to EXTRA_DIST.

2010-10-27T18:01:36+00:00

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1028056 13f79535-47bb-0310-9956-ffa450edef68

SASLizing Interbroker Links

2010-10-20T08:03:36+00:00

-------------------------------------------------------------

1. Brokers already knew how to handle the server side of SASLized
links, but not the client side. So we promoted the client-side
SASL code from the client library to the common library so that
the broker could also use it. This affected SaslFactory.{h,cpp}
and Sasl.h
TODO -- can the server-side and client-side code be unified here?

2. Some of the SASL verbs in broker/ConnectionHandler.cpp are
expanded: start, secure, tune.

3. broker/SecureConnection is altered to get the client-broker and
the server-broker to agree on when the security layer should be
inserted.

4. the python tool qpid-route is modified so that, in the "route add"
command, you can specify the security mechanism for SASL to use.
TODO -- should we also pass in {min,max}SSF ?

5. Changes in broker/LinkRegistry to allow the information input by
qpid-route to be passed up to where it is needed.

6. A bash script test run by "make check" that creates a SASLized
federation link and sends some messages down it.
TODO - write a python unit test instead of a bash script. I
think I uncovered a bug in the python code when I tried.

7. NOTE - testing for this feature does not work with versions of
SASL earlier than 2.1.22, becuase I can't tell SASL to use a
SASL database file in a nonstandard location. The test is
disabled for earlier versions.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1024541 13f79535-47bb-0310-9956-ffa450edef68

Fix problems with cluster_authentication_soak test in VPATH build.

2010-05-27T20:02:30+00:00

- Fix SASL version testing logic in cluster_authentication_soak and SaslAuthenticator
- Generate all SASL config in the build directory in sasl_test_setup.sh
- Compile cluster_authentication_soak only if SASL is available.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@948968 13f79535-47bb-0310-9956-ffa450edef68