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