The informational web page for the Jenkins CLI is reached via the URL [jenkins server URL]/cli in a web browser. Any attempt to actually use the CLI goes through the same URL. This presents a serious problem in the following case:

our organization provides authentication through a corporate servlet filter which must be enabled by adding a filter to web.xml:

<!-- Insert corporateLevel Security Framework -->
 <filter>
 <filter-name>Corporate Security Filter</filter-name>
 <filter-class>com.whatever.cadi.filter.CadiFilter</filter-class>
 <init-param>
 <param-name>cadi_prop_files</param-name>
 <param-value>/home/jenkins/jenkins/data/war/WEB-INF/cadi.properties</param-value>
 </init-param>
 <init-param>
 <param-name>cadi_noauthn</param-name>
 <!-- <param-value>/git:/jnlpJars:/css:/cli</param-value> -->
 <param-value>/git:/jnlpJars:/css:</param-value>

</init-param>
 </filter>
 <filter-mapping>
 <filter-name>Corporate Security Filter</filter-name>
 <url-pattern>/*</url-pattern>
 </filter-mapping>
 <!-- COPY END -->
 

Originally, this filter came with instructions to use the commented-out line

 <!-- <param-value>/git:/jnlpJars:/css:/cli</param-value> -->

But this provides a back door that allows non-authenticated users to access the web interface without going through the filter.

Changing it as we did above to

 <param-value>/git:/jnlpJars:/css:</param-value>

 stops this access but causes the cli not to work - attempts to access it by command such as

java -jar /path/to/jenkins-cli.jar -s http://[JENKINS_URL]/jenkins -http -auth @[HOME]/.jenkins-cli help

as described on the Jenkins CLI Http Connection doc gets transformed into

http://[JENKINS_URL]/jenkins/cli?remoting=false

and gives a 401 error.

Is there any reason WHY the URL accessing the cli itself has to be the same as the URL for accessing the information page about the CLI?  If the latter was accessible via a URL such as

http://[JENKINS_URL]/jenkins/cli-info

then the two cases could be differentiated and a filter such as described above could work correctly in both cases - preventing access to the info page just like the rest of the UI without authentication, but allowing actual command line access with the -auth mechanism.