More details on the precise location of the failure...
The namespace list in xpath code is automatically populated with all of
the namespaces listed in the web.xml file. In the wiki
WebContainerAuthorizer class there is a call to xpath add the "j" prefix
to the default namespace. The problem was that the namespace that was
declared in WebContainerAuthorizer and was trying to be set to 'j'
didn't match any of the namespaces in the web.xml file (i.e. xpath's
namespace list). So the call to add the "j" prefix didn't find a match
and therefore didn't get added to anything. But when the search was
next made for the "j:url-pattern" for Delete.jsp and Login.jsp,
j:url-pattern is not found since "j" was not added to any namespace.
The result was that wiki concluded WebContainer Authentication was not
active and therefore fell back to the custom auth code.
May have something to do with an earlier version of xpath ignoring the
'j' prefix in the search. But as soon as the WebContainerAuthorizer's
J2EE_SCHEMA_25_NAMESPACE variable was set to the namespace matching the
web.xml file's namespace declaration, it began to work fine.
Jerry
On 7/11/2019 5:00 PM, Jerry Malcolm wrote:
Hi Juan,
I'm running on WinServer16 with Tomcat 9.0.
Thanks.
Jerry
On 7/11/2019 4:53 PM, Juan Pablo Santos Rodríguez wrote:
Hi Jerry,
just out of curiosity, on what environment do you have deployed
JSPWiki? If
possible I'd like to take a look at the integration tests and
see if they can also be reproduced/run on it. Right now they were
running
against a vanilla tomcat and the bug wasn't detected.
Also, thanks for your time digging and hunting the issue! :-)
br,
juan pablo
On Fri, Jul 5, 2019 at 3:00 AM Jerry Malcolm <techst...@malcolms.com>
wrote:
Dirk,
Thank you SO MUCH for your work to get this fixed so quickly. That
fixed
my problem. I can now successfully log in. Life is good again with
JSPWiki and my clients.
Thanks again.
Jerry
On 7/4/2019 3:12 PM, Dirk Frederickx wrote:
Here is a link to the build artefacts.
https://builds.apache.org/job/jspwiki/lastSuccessfulBuild/artifact/
On Thu, Jul 4, 2019 at 9:59 PM Jerry Malcolm <techst...@malcolms.com>
wrote:
Dirk,
Does the M5 git fix still require a build? I can't seem to find a
WAR
file in the git tree.
On 7/4/2019 5:10 AM, Dirk Frederickx wrote:
Plz try deploying 2.11.0-M5-git-05
On Thu, Jul 4, 2019 at 10:28 AM Dirk Frederickx <
dirk.frederi...@gmail.com>
wrote:
Jerry, Ulf,
I can try to push a quick fix on WebContainerAuthorizer to github.
But I'm not able to fully test ; so appreciate if you can validate
this.
We also need to change the automated tests, cause those web.xml
are
also
pointing to the wrong namespace.
This can be done later.
dirk
On Thu, Jul 4, 2019 at 5:49 AM Jerry Malcolm
<techst...@malcolms.com>
wrote:
Update... I tried changing web.xml namespace back to sun. I found
that
version 2.10.0 had the sun site in web.xml. I copied the
web-app tag
and all of its attributes from 2.10.0 to the web.xml for my
2.11.0-M4.
No change. Stills says it's using custom auth. So I'm
assuming the
fix
has to be in the WebContainerAuthorizer.java class and requires a
rebuild, correct? Anybody already set up to make that change,
do a
new
build, and post a fixed jar file? (I assume turning new fix
releases
is
not quick....) I'm not thrilled about having to set up a build
environment. But if that's the only option.... :-(
On 7/3/2019 9:45 PM, Jerry Malcolm wrote:
Hey, Dirk,
Thanks so much for the info. You are correct that
WebContainerAuthorizer points to java.sun.com and the web.xml
points
to the javaee. What change do I make? Should I change the
web.xml
to
point to the sun site? I can't really change the
WebContainerAuthorizer code without doing a full rebuild. I
don't
have a build environment set up.
Jerry
On 7/3/2019 4:18 PM, Dirk Frederickx wrote:
Jerry, Ulf,
Probably the namespace used by
org.apache.wiki.auth.authorizer.WebContainerAuthorizer.java
is incorrect, as it still points to java.sun.com :
private static final String J2EE_SCHEMA_25_NAMESPACE = "
http://java.sun.com/xml/ns/javaee";;
The web.xml points to
http://xmlns.jcp.org/xml/ns/javaee
Could you check if that would help to fix this issue?
Not sure why this has not been catched by the tests.
Best regards,
dirk
On Wed, Jul 3, 2019 at 10:28 PM Jerry Malcolm <
techst...@malcolms.com>
wrote:
Thanks, Ulf. At least I know it's not just me. Are any
developers
of
JSPWiki monitoring this forum?
I debugged this down to the isConstrained(...) method in
org.apache.wiki.auth.authorizer.WebContainerAuthorizer.java.
I'm
not
sure of the reason for adding the "j:" tag qualifier prefix.
Comment
says it is required for J2EE 2.3. But it's searching for
<j:url-contstraint> and other "j:" tags in web.xml, which
aren't
there.
And the search is failing. So basically it is not finding
/Login.jsp
and /Delete.jsp constraints even though they are present and in
the
correct location (and uncommented). I tried adding the "j:"
prefixes to
my web.xml. But the webapp wouldn't even start with prefixes
manually
added. So the problem is straightforward. It may have
nothing
to
do
with the "j:" prefix. But that line that search for the
constraint
tag
is still failing. I ultimately get the log entry that says
"JSPWiki
is
using custom authentication." from the WebContainerAuthorizer
class
even
though web.xml is configured for container-managed
authentication.
So I'm dead with this release. Either I'm doing something
horribly
wrong or there is a serious bug in the WebContainerAuthorizer
code.
But
I've gone as far as I can go short of having to modify
JSPWiki and
build
my own release (which I do NOT want to do or have time to do).
Can someone tell me what I'm doing wrong and/or how many
releases
back I
have to go (and where to find archived releases) in order to
get
my
sites back online for my clients?
Will a developer PLEASE reply?
Jerry
On 7/3/2019 1:33 AM, Ulf Dittmer wrote:
I have not gotten container auth to work with 2.11.0.M3. I'm
quite
familiar
with Java web apps, so I know what to comment and what not in
web.xml,
but
no dice. I don't use SSO, though. But container auth works
fine
with
other
web apps on the same Tomcat instance.
Ulf
