I’ve having issues with some cookies, specifically JSESSIONID. Specifically when using ie11 and also specifically when I used a proxy server. Yes – the combination of all of these are causing me to have immediate “your session has expired” messages from JDE. This is a classic “load balancer not using JSESSIONID to manage web server affinity. We’ve all seen it 20 times before.
- The problem is that chrome works with the proxy
- The problem is that ie11 works without the proxy.
So where is my problem?
Let’s start with some basics.
The JDE login page needs to make 295 calls back and forth. This sends 172KB of traffic and receives 3.97MB. Did you know that? Cool stat!
The web server set’s a cookie almost immediately:
Key Value
Set-Cookie JSESSIONID=SoLLe2MGnfzecDkSIxm56qv8pf2a0SXrmjeRTFPGw84Xo8k89XBK!1342963082; path=/; HttpOnly
This expires at the end of the session. Easy!
Note that this is used for all of the exchanges of gif’s and css’s.
Now, we try and login.
The first time we do a MAF call, we have the cookie set on us to a different value
URL Protocol Method Result Type Received Taken Initiator Wait Start Request Response Cache read Gap
/jde/ResourceCanonicalsJS.mafService?e1UserActInfo=false&e1.mode=view&e1.namespace=&RENDER_MAFLET=E1Menu&e1.state=maximized&e1.service=ResourceCanonicalsJS HTTP GET 200 application/x-javascript 67.28 KB 78 ms <script> 1404 0 31 47 0 234
We send:
Key Value
Cookie _ga=GA1.1.1246774349.1489119748; _gat=1; JSESSIONID=u1jLgQJ7eBiRq9_cBQ3KPSUN71R2OmOJtgWRcpySaAWKc6gxlJrU!1830213081; e1AppState=
but, the server sends us:
Key Value
Set-Cookie JSESSIONID=eTnLgQfKjk4NyAAkLYm8XvOij6Oax5WNqwM0zgPaYhe78J5j_Rt1!1342963082; path=/; HttpOnly
So the browser can only use the new value in the next request (but we’ve flunked our session, as the cookie originally passed was invalid)
The interesting thing is, that when I remove the proxy, the JSESSIONID is being sent all of the time! Every request for a gif or png has the cookie in the request header. So the proxy or browser is ripping this out very early!
The reply from the server is pretty simple – I do not know you here is a new JSESSIONID if you want to try again.
{"notificationReply": {"idle":0, "timedout":true, "logoutURL":"/jde/MafletClose.mafService?action=close&e1UserActInfo=false&e1.mode=view&jdemafjasFrom=SessionTimeout&e1.namespace=&RENDER_MAFLET=E1Menu&e1.state=maximized&e1.service=MafletClose"}}
See that we have an appstate and now 2 session ID’s!
Direction Key Value Expires Domain Path Secure HTTP only
Sent JSESSIONID fwPLmXbOOv9FTQ1mY3cm_BFUAg3C5UuAfWmzDpK4T2as7ovnsVe4!1830213081
Sent e1AppState E1MENUMAIN_5531488967363928064:E1MENUMAIN_5531488967363928064|
Received JSESSIONID tgHLmXbO-vkMOxZmJr-1vfxgdeg7eJaq5JLxuYqLz5ljXrnUeEjn!1342963082 At end of session / No Yes
The client is doing a post of the following content
- Request headers:
- Key Value
- Request POST /jde/NotificationController.mafService HTTP/1.1
- Accept */*
- Referer http://jde92.xxxxx/jde/js/notificationWorker.js
- Accept-Language en-AU
- Content-Type text/plain;charset=UTF-8
- Accept-Encoding gzip, deflate
- User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
- Host jde92.xxxxx
- Content-Length 5
- Connection Keep-Alive
- Cache-Control no-cache
- Cookie _ga=GA1.1.1246774349.1489119748; JSESSIONID=FOLMOkDx9cu0Trx4oC7Joy24sGBo8pc-bdFde-mCP5vcDdCVrLY4!1342963082; _gat=1; e1AppState=E1MENUMAIN_3349205142792595456:E1MENUMAIN_3349205142792595456|
- Sent payload
- cmd=0
- cmd=0
The response from this request is the Set-cookie
Key Value
Response HTTP/1.1 200 OK
Date Tue, 14 Mar 2017 07:32:29 GMT
Content-Type text/html; charset=UTF-8
Set-Cookie JSESSIONID=YVbLu4qUOF1x4Fesurjkq-Fb-N54fgjN-sE0biUYng3md9cVHl5H!1830213081; path=/; HttpOnly
Content-Length 208
When chrome sends this – there is no reply with an alternate cookie in the header.
Wow, this is tough.. When you only have the client end of the comms – this is difficult to solve.
We got a LB consultant in who was able to hone in on LB side of things, and indeed was able to solve the problem. This is a complicated LB which actually detects the user agent and sends people to the appropriate JVM (because of activeX – if you know much about JDE you’ll understand this). This is a nice fix and some cool functionality to put into the LB.
The browser was sending Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko which is wrong.
What was happening was that the rules around IE vs. other browsers were being triggered by certain payloads (so the browser emulation went generic for some posts), which then went to a different LB member and everything broke. Wow!
What the consultant found was that JDE implemented this on some of their pages.
<meta http-equiv="X-UA-Compatible" content="IE=edge">
This client has “display intranet sites in compatibility mode”. Which meant that JDE was being displayed in compatibility mode. What this does is it overrides the "Compatibility View" settings on IE and forces the it to use IE11 (as opposed to IE7 which is the "Compatibility View" default). This explains why I was seeing the IE11 user agent on some requests, and the IE7 user agent on others.
Note that this causes the browser to disregard the payload and request it again using the compatibility settings. This means that accessing JDE in IE11 using compatibility mode and a fancy LB is going to break things every time. You need to be careful what headers you are going to use when directing traffic.
You can fix this with the LB rules and search for some different options, not just IE11 – search for the agnet rv:11 for example.
Lessons, shift ctrl I in chrome is awesome, F12 in iexplore is awesome. Browsers, proxies, compatibility mode and LB’s are complex beasts.
No comments:
Post a Comment