[Pki-devel] patch for review : https://bugzilla.redhat.com/show_bug.cgi?id=712931

[Adam Young]

I'm strill tracking down why the install failed.  So far, I can just 
determine that the CS DirSrv is not running when the ldap modify command 
comes through, but I am not sure why.


base/ca/shared/conf/proxy.conf

while it is a proxy to tomcat, from the apache perspective, tomcat is a 
subordinate.  It might not be the clearest name.  Perhaps 
proxy-tomcat.conf  or proxy-dogtag.conf,  although I thought 
dogtag.conf  was a fairly descriptive name.


All of the stanzas now appear identical with the exception of the 
LocationMatch and one with NSSVerifyClient require.   Can the 3 
NSSVerifyClient stanzas be collapsed   be collapsed into one?



ImportCAChainPanel.java:display

if this line fails:
context.put("machineName", cs.getString("machineName"));

The processing continue on, but the next two lines:
             context.put("https_port", 
cs.getString("pkicreate.ee_secure_port"));
             context.put("http_port", 
cs.getString("pkicreate.unsecure_port"));

Will never get executed.  THat doesn't seem like the intention we want.  
These two lines should probable be outside the catch block, and trigger 
an exception that stops processing, as it seems like things are 
significantly broken at this point.

AdminRequestFilter.java

Drop the bad_port boolean and move the conditional code up to where 
bad_port is set.

     if (bad_port) {
                     CMS.debug( filterName + ":  " + msg );
                     CMS.debug( filterName + ": uri is " + uri);
                     if ((param_active != null) 
&&(param_active.equals("false"))) {
                         CMS.debug("Filter is disabled .. continuing");
                     } else {
                         resp.sendError( 
HttpServletResponse.SC_NOT_FOUND, msg );
                         return;
                     }
                 }


AgentRequestFilter.java
EEClientAuthRequestFilter.java
EERequestFilter.java

Code is duplicate of the code in the AdminRequest\Filter.  refactor to a 
common method.  Comment from above applies here as well re:  bad_port

fixProxyPorts: Why catch the exception and continue.  Wouldn't it be 
better to throw the exception?  Do we really want to continue if this 
code does not succeed?


Relative paths in html files:  seesm like we should specify a place for 
the helper files to live, instead of assuming they will be in 
../cms-funcs.js  as that is a little on the fragile side. I am guessing 
that it can no longer be just /ee/  since we might be coming from 
/eeca/    Probably OK as is for this commit, but lets figure out what 
we'd ideally want to do.    I'm guessing that the eeca approach is 
really not what we want, and this is a work around for it, too.


I didn't give the perl code a thorough a look as the Java code, but it 
looked OK.