...
[15:11:09 CDT(-0500)] <jwennmacher> I assume same behavior if you just access https://my.wisc.edu.
[15:13:29 CDT(-0500)] <EricDalquist> right
[15:13:44 CDT(-0500)] <EricDalquist> the problem is cookieCheck just sends me back to https://my.wisc.edu/portal/Login
[15:13:50 CDT(-0500)] <EricDalquist> instead of https://my.wisc.edu/portal/Login?refUrl=%2Fportal%2Fp%2Ffinancial-information-resources
[15:15:20 CDT(-0500)] <EricDalquist> https://issues.jasig.org/browse/UP-3692
[15:16:17 CDT(-0500)] <jwennmacher> not sure I follow the last part. You mean after https://my.wisc.edu/portal/api/cookiecheck you go back to https://my.wisc.edu/portal/Login?
[15:16:30 CDT(-0500)] <EricDalquist> yup
[15:16:34 CDT(-0500)] <EricDalquist> but without the refUrl
[15:16:40 CDT(-0500)] <EricDalquist> so then I just end up at my default tab
[15:16:53 CDT(-0500)] <jwennmacher> Did you write up a Jira on the cookie check issues?
[15:17:18 CDT(-0500)] <EricDalquist> yup
[15:17:22 CDT(-0500)] <EricDalquist> I just create 3692
[15:17:25 CDT(-0500)] <EricDalquist> created*
[15:17:59 CDT(-0500)] <EricDalquist> ((HttpServletRequest) request).getSession(true).setAttribute(REFERER_ATTRIBUTE,((HttpServletRequest) request).getRequestURI());
[15:18:00 CDT(-0500)] <EricDalquist> yup
[15:18:31 CDT(-0500)] <EricDalquist> it is just using the URI
[15:18:44 CDT(-0500)] <EricDalquist> which doesn't include params
[15:26:01 CDT(-0500)] <jwennmacher> Do you know: If a load balancer is configured to use JSESSIONID for sticky sessions, is the request that creates the session guaranteed to be sent to the same server as the next request where the JSESSIONID is actually sent from the browser? It seems like it would have to be or you could end up in a loop, but then the load balancer would need to look at http responses and not just requests. (this assumes you load balance b
[15:28:04 CDT(-0500)] <EricDalquist> yes
[15:28:08 CDT(-0500)] <EricDalquist> that is how it should work
[15:28:09 CDT(-0500)] <EricDalquist> note if you do that
[15:28:21 CDT(-0500)] <EricDalquist> you need to tell your container you are doing so
[15:28:52 CDT(-0500)] <jwennmacher> you mean the concept is how it should work, or the latter part about session reusing the session ID?
[15:29:03 CDT(-0500)] <EricDalquist> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
[15:29:06 CDT(-0500)] <EricDalquist> see jvmroute
[15:29:14 CDT(-0500)] <EricDalquist> that concept is how it should work
[15:29:18 CDT(-0500)] <EricDalquist> though to be safe
[15:29:25 CDT(-0500)] <EricDalquist> you need to add a jvmroute param
[15:29:36 CDT(-0500)] <EricDalquist> so that you are ensured sessionids are unique across servers
[15:30:04 CDT(-0500)] <EricDalquist> we load balance
[15:30:08 CDT(-0500)] <EricDalquist> but we just do it by IP
[15:42:56 CDT(-0500)] <jwennmacher> So jvmroute is different per server to insure unique ids?
[15:43:01 CDT(-0500)] <EricDalquist> yeah
[15:43:09 CDT(-0500)] <EricDalquist> it just appends that value to the jsessionid I believe
[15:48:37 CDT(-0500)] <EricDalquist> so jwennmacher I think I have a fix
[15:48:39 CDT(-0500)] <jwennmacher> OK. I glanced through the info. Thanks for pointing it out to me. The concept sounds fine. I think it answers my question for at least some scenarios. If using tomcat's clustering approach (software-based clustering), the use of the jvmroute will ensure that if request #1 creates the http session, request #2 will go back to the same server because of this route indication (if I'm following it right).
[15:48:42 CDT(-0500)] <EricDalquist> pushing it out locally now
[15:48:53 CDT(-0500)] <EricDalquist> and I'll push it into jasig's repo tomorrow morning
[15:49:00 CDT(-0500)] <jwennmacher> sounds great.
[15:52:48 CDT(-0500)] <jwennmacher> So I guess the scenario I'm not sure is if you have an external (hardware) load balancer and you choose to use an http header field like JSESSIONID instead of IP address, if an http request comes in and I create a session and store a value into session, am I guaranteed the next request will come to the same server. I think I am if the tomcat clustering approach you mentioned is used, or if a load balancer is set for IP-bas
[15:53:19 CDT(-0500)] <EricDalquist> I think so
[15:53:24 CDT(-0500)] <EricDalquist> the session id won't change
[15:53:33 CDT(-0500)] <EricDalquist> but I have to run
[15:53:38 CDT(-0500)] <EricDalquist> see you tomorrow
[15:53:39 CDT(-0500)] <jwennmacher> OK. Thanks.
[15:53:42 CDT(-0500)] <jwennmacher> you bet