Re: SSO Token not found with RewriteRules
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
Re: SSO Token not found with RewriteRules
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,
Re: SSO Token not found with RewriteRules
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO Token not found with RewriteRules
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
Re: SSO Token not found with RewriteRules
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-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
