Hi Hermant,


On 27/11/2017 20:31, Coscend@HAProxy wrote:
>
> Hello Moemen,
>
>  
>
> Thank you and very thoughtful of you to educate us on how HAProxy
> handles Websockets and logs cookies.  Guidance such as these have
> helped us grow from a rank startup to offer SLA-based healthcare
> services to disadvantaged remote areas (where there are no
> hospitals/clinics) through our Web-based products.  These patients
> indirectly benefit from your guidance, besides us who benefit directly.
>
>  
>
> --------
>
It is great to know that HAProxy is contributing to such projects :)

> Without the cookie in the request of the login page, our users are
> unable to login into the product.  Going by your guidance, it would be
> advisable to insert the JSESSIONID received in server response back
> into the client request.  This will help our product server
> authenticate users to login.  Are we on the right path?
>
If a server is inserting a cookie when replying to HAProxy, then HAProxy
should send that cookie when replying to the client (unless you are
asking explicitly HAProxy to remove the cookie). So I am almost sure
that if there is no cookie logged then that is because there is actually
no cookies sent (via set-cookie).

> https://www.haproxy.com/documentation/aloha/8-5/haproxy/traffic-capture/ 
> àInsert a cookie if none presented by the client
>
>  
>
> If we need to course correct, please advise alternatives.
>
>  
>
> As advised, we are using for Websockets
>
> backend subdomain_cc
>
>     timeout tunnel  3600s         
>
I am not sure this is going to help as you don't just need to insert a
cookie but you need to have a cookie with the right value to make this
work. (Unless I am mistaken about how your app works)


I think we are being confused by the whole Websocket thing while it
**shouldn't be** the case.
Sorry for the confusion but Websocket is probably not the problem here.
So I am going to get back to some of your previous questions in order to
make this clearer.
>
>  
>
>  
>
> *From:*Moemen MHEDHBI [mailto:mmhed...@haproxy.com]
> *Sent:* Monday, November 27, 2017 1:15 PM
> *To:* haproxy@formilux.org
> *Subject:* Re: HAProxy 1.7.9 Not Capturing Application Session Cookie
>
>  
>
> Hi Hemant,
>
> When using websocket, HAProxy will switch to tunnel mode whenever it
> detects the Connection: Upgrade header.
>
> Tunnel mode means that only the first request and response are
> processed and logged and everything else will be forwarded with no
> analysis, I think this is what happens with your 3.3.2 version.
> Normally you will only be able to see the cookie in the log if it is
> present in the request initiating the websocket connection.
>
> On the other hand, with your 3.3.0 version, HAProxy works in the
> default keep-alive-mode where every request is processed and logged.
>
> ++
>
>  
>
> On 24/11/2017 23:30, Coscend@Coscend wrote:
>
>     Hello Moemen,
>
>      
>
>     Thank you for your encouraging insights.  Below is the information
>     you asked. 
>
>      
>
>     >>Also you mentioned  the application extensively uses Websockets. Is it
>     only 3.3.2 using websockets ? if that is the case this may be a
>     good lead since HAProxy does not handle websockets traffic in the
>     same way as it does for normal http traffic.
>
>      
>
>     Yes, only v. 3.3.2 uses Websockets.  (v. 3.3.0 did not use
>     Websockets and access via HAProxy was seamless.)
>
>      
>
>     Could you please educate us on what configuration changes we need
>     to do for Websockets traffic (vs. HTTP traffic)?
>
Basically, There is nothing really that have to be changed in your
HAProxy configuration with your 3.3.2 version, as long as you are
sending the cookie in the same way (cookie header).
Your new app will be talking HTTP (and that is where cookies and headers
can be processed) then when switching to websocket we don't have to talk
any more about the JSESSIONID or anything else related to HTTP.

>      
>
>     >>In your first post you said that it is working for 3.3.0 but not
>     3.3.2, then maybe this is an application issue. Are you sure 3.3.2
>     does sent the JSESSIONID.
>
>      
>
>     Yes.  Please see below JSESSIONID in the login page URL loaded,
>     HAProxy logs and product log.  Is there any other way to verify
>     whether the v. 3.3.2 is publishing JSESSIONID?
>
I think this is the most important part, you need to know when the
JSESSIONID cookie is being sent and if it is the case then you should be
able to see that in HAProxy logs.
>
>      
>
>     Through HAProxy, login page URL loads with a JSESSIONID: 
>     
> https://coscend.com/CoscendCC.Test/signin;jsessionid=E916C54BB7A9EA30E3EC9021AEF4CB79
>
Ah .. I have overlooked that cookie in the URL and I think this is the
problem here. HAProxy won't capture cookies as they are part of the URL.
You can do the following tests:
- curl
https://coscend.com/CoscendCC.Test/signin;jsessionid=E916C54BB7A9EA30E3EC9021AEF4CB79
: no cookie logged.
- curl -b jsessionid=E916C54BB7A9EA30E3EC9021AEF4CB79
https://coscend.com/CoscendCC.Test/signin
<https://coscend.com/CoscendCC.Test/signin;jsessionid=E916C54BB7A9EA30E3EC9021AEF4CB79>
: Then you can see the cookie in the logs.

I am not really confortable with J2EE but I would like to ask why the
client is sending the cookie this way ? and if you send it normally
(cookie header) does this solve your problem ?

++

-- 
Moemen MHEDHBI

Reply via email to