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