You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jerry Malcolm <te...@malcolms.com> on 2023/01/16 06:40:03 UTC
SSO Token not found with RewriteRules
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSO Token not found with RewriteRules
Posted by Jerry Malcolm <te...@malcolms.com>.
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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] SSO Token not found with RewriteRules
Posted by Christopher Schultz <ch...@christopherschultz.net>.
On 1/24/23 08:04, Berneburg, Cris J. - US wrote:
> Hey Chris
>
>> I always include a ROOT context so I don't get nasty errors if
>> there is some kind of misconfiguration at the proxy, etc. It also
>> allows rewrites to be done "outside" of "the application", etc.
>
> Out of curiosity, what do you put in that ROOT context? A dummy / placeholder or the real application?
It consists of a (nearly) empty WEB-INF/web.xml and META-INF/context.xml
file and nothing else. It exists to generate 404 responses to anything
outside of the actually-deployed web applications.
Otherwise you get a 400 response to anything not in
/real-deployed-application/*
Or at least it did a million years ago when I started doing things this way.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] SSO Token not found with RewriteRules
Posted by "Berneburg, Cris J. - US" <cb...@caci.com.INVALID>.
Hey Chris
> I always include a ROOT context so I don't get nasty errors if
> there is some kind of misconfiguration at the proxy, etc. It also
> allows rewrites to be done "outside" of "the application", etc.
Out of curiosity, what do you put in that ROOT context? A dummy / placeholder or the real application?
--
Cris Berneburg
CACI Senior Software Engineer
________________________________
This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] SSO Token not found with RewriteRules
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Jerry,
On 1/17/23 13:30, Jerry Malcolm wrote:
> 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.
I always include a ROOT context so I don't get nasty errors if there is
some kind of misconfiguration at the proxy, etc. It also allows rewrites
to be done "outside" of "the application", etc.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSO Token not found with RewriteRules
Posted by Jerry Malcolm <te...@malcolms.com>.
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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSO Token not found with RewriteRules
Posted by Mark Thomas <ma...@apache.org>.
On 17/01/2023 09:43, 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.
Quick question. Is the SingleSignOn valve configured before the Rewrite
valve in your Host?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSO Token not found with RewriteRules
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSO Token not found with RewriteRules
Posted by Jerry Malcolm <te...@malcolms.com>.
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.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org