On 1/17/2023 12:30 PM, Jerry Malcolm wrote:
On 1/17/2023 3:43 AM, Mark Thomas wrote:
On 16/01/2023 23:07, Jerry Malcolm wrote:
Well, after downloading and installing the Tomcat source in my
Eclipse environment and tracking through a bunch of breakpoints, I
figured out what was happening. SingleSignOn.invoke() was querying
for the list of cookies in the request (that were indeed present in
the request), but was returning null. Since no cookies were 'found'
there was no JSESSIONIDSSO cookie found, and everything failed from
that point on. So I started tracking why the cookies that were
present were being ignored. convertCookies was called, which did a
getContext() which returned null, so everything aborted.
getContext() failed apparently because I did not have a ROOT webapp
(context) defined. I added a dummy ROOT webapp, and voila....
So.... the bottom line to the entire problem is that RewriteRules
with SSO is not permitted UNLESS there is a dummy ROOT webapp
defined. I'm not sure why this would be a requirement, and I was
not able to find any documentation about it. I understand why SSO
might require contexts. But the primary purpose of RewriteRules is
to hide the plumbing on the URL line. If the requirement for
context present is required for SSO, then it would seem to me that
the context should be checked on the target of the rewrite, not the
original string being rewritten, since it most likely will not have
a valid context. And a dummy unused ROOT webapp just takes up
resources. The reason it worked in the other virtual host is that I
actually did have a need in that host for a ROOT context.
This one was painful. Just out of curiosity, is this restriction
intended? If so, error messages and/or documentation of it might
need a review.
No. The restriction isn't intended. See this discussion around a
similar issue:
https://github.com/apache/tomcat/pull/479
Generally, not having a ROOT context is sufficiently unusual that it
is rare for users to fund bugs like this.
A similar approach should fix this - assume the default
CookieProcessor if no context is found.
Mark
Thanks for the reply, Mark. In my philosophy for years (possibly not
the best philosophy...), the root was for primarily static stuff. And
any JSPs that might need to be in root were sent to other non-root
contexts via a rewrite. I've been moving away from that philosophy in
recent projects and including a ROOT context. But this current
situation is migrating a legacy domain off of httpd/tomcat to pure
tomcat. So it bit me. No big deal now that I've figured it out.
The cookie processing was inside the Tomcat request object. So I
assume that statement about using the default CookieProcessor was
meant for TC development. Or is there a way I can control which
cookie processor is used?
Thanks again... on to the next hill to climb.
Jerry
Mark,
You know a day or two earlier it crossed my mind that order of the
valves might be significant. I was convinced that if I found out
'working host A' and 'non-working host B' had the valves declared in
different orders then obviously problem solved... But then I saw that
they both had SSO above rewrite, and since they were identical and one
worked, one didn't, that couldn't be the problem. But now that you
mentioned it, I'm wondering if the order could be significant, and
having the ROOT domain defined simply masked the ordering differences.
If I get some time to play, I'll re-order them and pull the ROOT context
temporarily and see what happens.
Thanks.
Jerry
On 1/16/2023 12:40 AM, Jerry Malcolm wrote:
I have one virtual host working fine on a Windows 11 TC 9 install.
I am adding a 2nd virtual host to that same running installation.
This TC is standalone, handling http requests directly (not via
httpd). Both virtual hosts have a rewrite.config. On the new
domain, I go to a page that requires a login, do the standard
login, and it show the page. I can F5 refresh the page and it
continues to appear. But if I enter a url that redirects to this
same page, I get the signin screen. If I try to sign in again, I
get an error "The requested resource [/idmanager/j_security_check]
is not available" I enabled redirect logs, and they show SSO token
not found. I know the redirect is working fine for the new
virtual host since there's no problems going to unprotected (no
sign-in) redirected pages.
This exact scenario works perfectly fine (with rewrite rules) on
the other virtual host in the same TC. I've compared the two host
configurations in server.xml and they appear identical other than
than the name and path. i.e. SingleSignOn valve is specified on both.
The fact that SSO only fails on redirects and not on URLs without
redirects, plus the fact that it works fine on one virtual host and
not on the other is baffling me. All indications point to some
sort of config error or typo on the something in the new virtual
host. But I have spent more hours that I want to admit on this,
and I simply can't figure out anything that would cause this. I'm
sure I made some config change somewhere a long time ago on the
first virtual host that's making it work correctly. But I can't
find anything, and I'm at a total loss.
What could be causing rewrite rules to not find SSO cookies? Where
did I mess up?
Thanks
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org