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.
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
