JUDDI-920 updating documentation JUDDI-906 adding additional 'just in case' code to assist with cleanup
Project: http://git-wip-us.apache.org/repos/asf/juddi/repo Commit: http://git-wip-us.apache.org/repos/asf/juddi/commit/53d6f2d2 Tree: http://git-wip-us.apache.org/repos/asf/juddi/tree/53d6f2d2 Diff: http://git-wip-us.apache.org/repos/asf/juddi/diff/53d6f2d2 Branch: refs/heads/master Commit: 53d6f2d2c1b8322c6382c154e4fa32ab38eb5dd5 Parents: 86d58ae Author: Alex <[email protected]> Authored: Sat Jan 17 11:36:29 2015 -0500 Committer: Alex <[email protected]> Committed: Sat Jan 17 11:36:29 2015 -0500 ---------------------------------------------------------------------- .../Guide/en-US/GuideAdministration.asciidoc | 12 ++++-- .../en-US/GuideConfigurationServer.asciidoc | 1 + .../tck/JUDDI_300_MultiNodeIntegrationTest.java | 39 ++++++++++++++++---- 3 files changed, 42 insertions(+), 10 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/juddi/blob/53d6f2d2/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc ---------------------------------------------------------------------- diff --git a/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc b/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc index a6eaf9c..9cebbcd 100644 --- a/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc +++ b/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc @@ -12,6 +12,8 @@ jUDDI Server (Tomcat) - This assumes you are using the jUDDI server bundled with - Edit `webapps/juddiv3/WEB-INF/config.properties` and change the port numbers for "securityurl" and "juddipapi". - Edit `webapps/juddi-gui/META-INF/config.properties` and change the port numbers for all of the URLs listed. +If these changes are made before jUDDI has been started for the first time, then no further action is required. If jUDDI has been previously started, you'll need to either A) update the URL information for the Node's root business entity URLs or B) turn on "Seed Always" in the juddiv3.xml file to auto update the changes. + === Administering Users and Access Control As of version 3.2, jUDDI Authentication is handled from two perspectives, administrator and end user access. @@ -195,20 +197,24 @@ juddi/auth/securityDomain=java:/jaas/other ---- The juddi/auth/authenticator/class property plugs the JbossAuthenticator class into the jUDDI the Authenticator framework. The juddi/sercuityDomain, configures the JBossAuthenticator class where it can lookup the application server's security domain, which it will use to perform the authentication. Note that JBoss creates one security domain for each application policy element on the `$JBOSS_HOME/server/default/conf/login-config.xml` file, which gets bound to the server JNDI tree with name java:/jaas/<application-policy-name></application-policy-name>. If a lookup refers to a non existent application policy it defaults to a policy named other. -===== Contained Based Authentication +===== Container Based Authentication Certain security configurations may use HTTP based authentication. In this scenario, jUDDI simply trust's that the container will authenticate the user via some mechanism and uses that username for interactions with jUDDI. To configure this setup, use the following configuration settings in juddiv3.xml: ---- juddi/auth/authenticator/class=org.apache.juddi.auth.HTTPContainerAuthenticator +juddi/auth/authenticator@useAuthToken=false ---- +In addition, you'll have to make whatever changes necessary to the juddiv3.war/WEB-INF/web.xml file in order to use the chosen authentication mechanism. See your appliation server's documentation for details on this. + -===== Authentication by Proxy +===== Authentication by Proxy (HTTP Header) -Certain security configurations that enforce authentication before requests come to the web application, such as via Apache HTTPD or a reverse SSL proxy. In these cases, the proxy provide authenticates the user, then passes along the user's identity via a HTTP header. To configure this setup, use the following configuration settings in juddiv3.xml: +Certain security configurations that enforce authentication before requests come to the web application, such as via Apache HTTPD or a reverse SSL proxy. In these cases, the proxy provided authenticates the user, then passes along the user's identity via a HTTP header. To configure this setup, use the following configuration settings in juddiv3.xml: ---- juddi/auth/authenticator/class=org.apache.juddi.auth.HTTPHeaderAuthenticator juddi/auth/authenticator/header=(Some HTTP Header) +juddi/auth/authenticator@useAuthToken=false ---- [[ConfiguringDatabaseConnections]] http://git-wip-us.apache.org/repos/asf/juddi/blob/53d6f2d2/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc ---------------------------------------------------------------------- diff --git a/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc b/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc index 6f36b90..cb746ed 100644 --- a/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc +++ b/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc @@ -20,6 +20,7 @@ IMPORTANT: When referring to configuration 'properties', we are really referenci |_juddi/auth/token/Timeout_ |Time in minutes to expire tokes after inactivity.|N |_15_ |_juddi/auth/token/Expiration_ |As of 3.1.5 Duration of time for tokens to expire, regardless of inactivity.|N |_15_ |_juddi/auth/token/enforceSameIPRule_ |As of 3.2 This setting will enable or disable the auth token check to ensure that auth tokens can only be used from the same IP address that they were issued to..|N |_true_ +|_juddi/auth/authenticator@useAuthToken | Indicates that the authenticator is use requires a UDDI auth token. Set to false when using HTTP based authenticators | N | _true_ |=========================================================================================== http://git-wip-us.apache.org/repos/asf/juddi/blob/53d6f2d2/uddi-tck/src/test/java/org/apache/juddi/v3/tck/JUDDI_300_MultiNodeIntegrationTest.java ---------------------------------------------------------------------- diff --git a/uddi-tck/src/test/java/org/apache/juddi/v3/tck/JUDDI_300_MultiNodeIntegrationTest.java b/uddi-tck/src/test/java/org/apache/juddi/v3/tck/JUDDI_300_MultiNodeIntegrationTest.java index 008851f..86afb69 100644 --- a/uddi-tck/src/test/java/org/apache/juddi/v3/tck/JUDDI_300_MultiNodeIntegrationTest.java +++ b/uddi-tck/src/test/java/org/apache/juddi/v3/tck/JUDDI_300_MultiNodeIntegrationTest.java @@ -466,7 +466,7 @@ public class JUDDI_300_MultiNodeIntegrationTest { * @throws Exception */ @Test - // @Ignore + // @Ignore public void testReplicationTModelBusinessPublisherAssertionAddDelete() throws Exception { Assume.assumeTrue(TckPublisher.isReplicationEnabled()); Assume.assumeTrue(TckPublisher.isJUDDI()); @@ -479,7 +479,7 @@ public class JUDDI_300_MultiNodeIntegrationTest { TModel saveMaryPublisherTmodel = maryTModelNode1.saveMaryPublisherTmodel(maryTokenNode1); samTModelNode2.saveSamSyndicatorTmodel(samTokenNode2); - + BusinessEntity saveMaryPublisherBusiness = maryBizNode1.saveMaryPublisherBusiness(maryTokenNode1); // TModel saveSamSyndicatorTmodel = samTModelNode2.saveSamSyndicatorTmodel(samTokenNode2); @@ -980,7 +980,9 @@ public class JUDDI_300_MultiNodeIntegrationTest { // TckCommon.PrintMarker(); } finally { - /*try { + TckCommon.PrintMarker(); + logger.fatal("The test failed, attempting to clean up the business and tModels"); + try { DeleteBusiness db = new DeleteBusiness(); db.setAuthInfo(samTokenNode2); db.getBusinessKey().add(TckBusiness.SAM_BUSINESS_KEY); @@ -994,8 +996,6 @@ public class JUDDI_300_MultiNodeIntegrationTest { logger.info("Waiting for the update..."); try { tModelDetail = inquiryMary.getBusinessDetail(findTModel); - // JAXB.marshal(tModelDetail, System.out); - // } catch (Exception ex) { logger.warn(ex.getMessage()); tModelDetail = null; @@ -1014,8 +1014,7 @@ public class JUDDI_300_MultiNodeIntegrationTest { } catch (Exception ex) { ex.printStackTrace(); - Assert.fail(ex.getMessage()); - }*/ + } resetTmodels(); } @@ -1215,4 +1214,30 @@ public class JUDDI_300_MultiNodeIntegrationTest { } + /** + * If the same key is created at two nodes before the replication change + * record has been distributed, it's possible for the same record to be + * owned by two different nodes. After a short period of time, both + * records should be rejected + * + * <a href="http://www.uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908178";>7.3.9</a> + * for more info on collision detection + * + * @throws Exception + */ + @Test + @Ignore + public void replicationConflictMaintainOwership() throws Exception { + try { + resetTmodels(); + + maryTModelNode1.saveMaryPublisherTmodel(maryTokenNode1); + samTModelNode2.saveMaryPublisherTmodel(samTokenNode2); + + } finally { + resetTmodels(); + } + + } + } --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
