We are in the process of migrating our on-prem environment to GCP. In our on-prem environment, we have an F5 Application Load Balancer(LB) that routes traffic to app nodes based on JSESSIONID cookie. The way it works is,
If the incoming request to LB doesn't have the JSESSIONID cookie then request is forwarded to one of the available app node in the pool in round robin fashion
If the request does have JSESSIONID, then the request is forwarded to the app node that previously set the cookie
How do I replicate this in GCP internal Load Balancer? If I set session affinity based JSESSIONID cookie, the load balancer creates a cookie before forwarding the request to the app node. This as a result causes the browser to receive two set-cookie for JSESSIONID on the response.
Related
I have an application which uses AWS load balancer. The application shows that the AWSALB Cookie is not marked with the "secure" attribute.Attached image shows the cookies used in the application where AWSALB cookie marked without secure attribute
recently we had switched from aws elb to aws alb; but we are facing issue in aws alb; cookie stickiness is not working at all; for each request (event ajax request on the page) generates a new cookie;
if we switch back to aws elb again cookie stickiness working perfectly fine.
AWSALB is a cookie generated by the Application load balancer in the AWS. It works slightly different from AWSELB.
The ASWALB cookie is load balancer generated cookie. Once the load balancer routes your request to one of the servers, it generates a new cookie and sends it to the client in the response header. Though AWSALB works fine when you just send the webapp_session for consecutive request, it is better to integrate the AWSALB cookie along with the webapp_session and send it for each request to the server. This way, the load balancer will identify your target server and direct your request to the same target in each request call to the server. This preserves the stickyness of the server.
However, if you send AWSALB along with the webapp_session in the request header for each request to the sever, even if the target that processed your previous requests gets busy for future requests, the AWSALB generated in each call will help the load balancer identify your credentials and route your request to the new target. I faced similar situation and this helped me solve the problem.
The "STICKY SESSION" topic in this https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions will perhaps help you have some idea.
For Application LB you have to set up session stickiness in target group not directly in LB like in Classic LB. Session stickiness doesn't work when your browser blocks AWSALBCORS, AWSALB - this seems to be obvious, but Internet Explorer can block these cookies and doesn't show any warning/info in console.
Observations
When using an Amazon ELB Application Load Balancer and working with Sticky Sessions the load balancer inserts a cookie named AWSALB in the first request. To let the next request stick to the same target node (EC2 instance) the cookie should be included in that request. When doing so, it seems that the load balancer inserts a different cookie value in the response to the 2nd request. When including this new cookie value on the 3rd request, we get yet a new cookie value in the response. And so forth…
(This is different from how Sticky Sessions works with the Classic Load Balancer where the cookie is named AWSELB and retains its value until discarded by the client or the load balancer.)
The reason the AWSALB cookie changes value all the time seems to be (as stated by the docs):
The name of the cookie is AWSALB. The contents of these cookies are encrypted using a rotating key. You cannot decrypt or modify load balancer-generated cookies.
So even though the contents of the cookie might be the same, we cannot tell.
Question
The question is whether a request to the load balancer must always include the most recently received value of the AWSALB cookie or if it ok to send some previously received value (from the same sticky session, of course).
If this is a requirement the AWS ELB Application Load Balancer would not be able to serve a client that performs multiple parallel requests (after having received the first AWSALB cookie) but only clients that performs all requests in a sequential fashion (one at a time).
Can anybody shed some light on this?
After waiting for a reply here, I raised a support case with Amazon and got this reply:
I understand that you would like to confirm if it is required to provide the latest stickiness cookie for every request.
You are right in noting that the behaviour is different between CLB and ALB.
Due to the different functionality of Application Load Balancer to direct traffic to multiple Target Groups, each having its own stickiness, ALB encrypts the information needed to direct traffic and provides new cookie on each request. This ensures that different times for different groups are always respected correctly.
Clients can always obtain the latest cookie, as internally the information would ensure correct routing to the same target.
If you want to reuse single cookie it is also possible, ALB will respect it and correctly route the traffic as per the stickiness in the cookie. I would not recommend using the same cookie for periods longer than 60 seconds though. This is to ensure that in case of target becoming unavailable you can acquire new cookie with new stickiness information that would route you to new target.
The load balancer must always include the most recently received value of the AWSALB cookie - yes. Some text from the documentation:
The Application Load Balancer resets the expiry of the cookies it generates after every request.
Sticky sessions for your Application Load Balancer
I am running a tomcat web application on AWS Elastic Beanstalk using load balancing. I have two cookies for each session (1) JSESSIONID (2) XSRF-TOKEN (csrf token*).
I set the JSESSIONID as the application-controlled session stickiness cookie, in Load Balancer Port Configuration. It works perfectly. But I can not set the second session cookie as it is only possible to set ONE sticky cookie in the Load Balancer.
Any idea how I can set multiple cookies for a session in Elastic Beanstalk Load Balancer?
I appreciate your help as Im stuck with this big time!
Migan
*On every request to the backend, backend generates an CSRF-TOKEN and hands it over to the client by setting it as an HTTP response header. The client is required to submit this token on every state changing request in order to prevent cross-site request forgery.
Problem solved!
The reason I could not see my XSRF_TOKEN cookies was that in the test environment I was using http to access my ElasticBeanstalk environment. Once I generate an SSL certificate and accessed my instance using https, my lovely XSRF_TOKEN cookie appeared again!
I am using Service Bus 11gR1
I have created a proxy service
I can view it's WSDL if I point my browser to:
https://wlsdev.mydomain.com/osb/RJMTest/XXIC_ErrorQueryAsync_Proxy?wsdl
When I look at the returned WSDL I can see the binding element lists the actual host rather than the load balancer:
</WL5G3N0:binding>
<WL5G3N0:service name="query_ptBindingQSService">
<WL5G3N0:port binding="WL5G3N2:query_ptBinding" name="query_ptBindingQSPort">
<WL5G3N3:address location="http://internalserver.com:8010/osb/RJMTest/XXIC_ErrorQueryAsync_Proxy"/>
</WL5G3N0:port>
</WL5G3N0:service>
My question is what setting in OSB do I need to change to alter what the SOAP wsdl is using to generate the WSDL?
(In SOA there was a ServerURL setting)
You will have to update the cluster http frontend host to the load balancer address. This will need to be done on WebLogic Admin console
Login to http://{host}:{port}/console
Clicked on Lock and Edit button
Select Cluster
Click on HTTP
Configure Front End Host address to the pool name of load balancer
Configure http and https port where managed servers listen to
Click Save.
You will need to restart the managed servers.