Hi Colin, yes, you link it above, this problem of changing client's IP addresses was already reported in here: Cookies Problem in Clustered Environment <https://groups.google.com/a/apereo.org/g/cas-user/c/R4WVT4Tq0g8/m/j9WpuuMGAgAJ> .
And the logging problem you describe? It is still there as well, only in another form, I reported this myself: Invalid constructor of InvalidCookieException - useless log message <https://groups.google.com/a/apereo.org/g/cas-user/c/DYy7_M8VPKU>. I think the simplest (although not the safest) solution is to simply remove the IP address check from DefaultCasCookieValueManager - I think CAS authors should have made this *configurable*. As some clients may also have dynamic IP address assigned nowadays. Should we create a pull request? On Tuesday, 13 December 2016 at 21:30:56 UTC+1 [email protected] wrote: > On this issue during our problems I picked the following bit of code, it > was masking a problem we were having. When > the CookieRetrievingCookieGenerator class retrieveCookieValue methods > calls DefaultCasCookieValueManager class obtainCookieValue method it was > failing as the remoteAddr had been changed to one of two IP address and > therefore the IP address was not always the same. > > The error being thrown. > public String obtainCookieValue(final Cookie cookie, final > HttpServletRequest request) { > ........ > if (!remoteAddr.equals(request.getRemoteAddr())) { > throw new IllegalStateException("Invalid cookie. Required > remote address does not match " > + request.getRemoteAddr()); > } > } > > But the problems lies within the retrieveCookieValue method. Highlight in > bold is a logger.debug statement that should be a logger.error statement. > public String retrieveCookieValue(final HttpServletRequest request) { > try { > final Cookie cookie = > org.springframework.web.util.WebUtils.getCookie( > request, getCookieName()); > return cookie == null ? null : > this.casCookieValueManager.obtainCookieValue(cookie, request); > } catch (final Exception e) { > *logger.debug(e.getMessage(), e);* > } > return null; > } > > Regards, > Colin > > > > > > On Tuesday, 13 December 2016 19:15:56 UTC+11, Colin Wilkinson wrote: >> >> Our issue turns out to be related to the f5 overiding the remoteAddr with >> another value and once we set the remoteAddr back to the original value >> using tomcat all is good. >> >> Related CAS issue. >> <https://groups.google.com/a/apereo.org/forum/#!topic/cas-user/R4WVT4Tq0g8> >> >> Related tomcat page >> <https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html> >> >> On Tuesday, 13 December 2016 07:31:19 UTC+11, Colin Wilkinson wrote: >>> >>> Hi, >>> >>> We seem to have an strange problem every now and then. We people are >>> already signed into the Portal and click another link that uses CAS at >>> times they are being asked to resign in, but other times it works just fine. >>> >>> Anyone seen this problem and is able to help. This is only happening in >>> production from what we can tell. >>> >>> Our CAS environment is >>> CAS 4.1.7 >>> With SPNEGO set to mix mode on, so that it redirects to the login page >>> if not able to SSO. >>> Apache HTTP 2.2 >>> Apache Tomcat 8.0.33 >>> >>> Regards, >>> Colin >>> >> -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/59795c92-f596-4565-b850-cc3bbb965313n%40apereo.org.
