Jump to content


Photo

Loadbanced storefront multi-server group issue and CsrfToken

Started by Christos Giotis , 10 March 2017 - 12:39 PM
6 replies to this topic

Christos Giotis Members

Christos Giotis
  • 5 posts

Posted 10 March 2017 - 12:39 PM

Hello we have the following issue using NS load balanced Storefront  muti-server group.  
 
The LB is configured as default with sourceip persistance timeout=2mins.
 
Scenario
  1. User logged through Access Gateway and the LB redirects the connection to Storefront1. New session created on Storefront1  and the client receives a csrftoken=1xxxxxx
  2. After 3mins the user tries to open an application the LB redirects the connection to Storefront2. The user gets the message "your session has expired ...please press ok" and user press  click to OK button. So a new session is created to Storefront2 and the client receives a new csrftoken=2XXXXX.
  3. After 3 mins  the user tries to open an other application the LB redirects back to Storefront1 and gets the error "Cannot complete your request" in HTTP level the response from storefront1 is "403 Frorbiden. Access Denied. "  and I realized that the client has sent the csrftoken=2XXXXX  which is not the same with session  on Storefront1. (See csrftoken on step 1. )
 
So is the above process  an expected behavior ? Is there something that should change in storefront  in order to avoid the error message caused by csrftoken?

 

 

 

 

 

 

 



Paul Blitz Members

Paul Blitz
  • 3,696 posts

Posted 10 March 2017 - 08:32 PM

go to the loadbalancer and change the persistence timeout from 2 mins to 30 mins



Christos Giotis Members

Christos Giotis
  • 5 posts

Posted 11 March 2017 - 07:18 AM

Hi Paul thank for your suggestion. But why especially 30 minutes do you think  that will solve our issue just extending the timeout time?

Ι would like to mention that we get occasionally the error  "cannot your request" after  upgrade storefronts version from 2.5 to 3.5



Feng Huang Citrix Employees

Feng Huang
  • 565 posts

Posted 20 March 2017 - 10:08 AM

Receiver for Web (RfWeb) is session-based and requires sticky load balancing to ensure that requests during the http session are all directed to the same server. It is better to use cookie-insert LB persistence unless you have to support native Receiver for Android. If you have to use source ip LB persistence, you have to make sure that timeout is long enough for a typical RfWeb session. By default, RfWeb session times out after 20 minutes idle time. Please note that it is idle time, not fixed duration.


Helpful Answer

Paul Blitz Members

Paul Blitz
  • 3,696 posts

Posted 20 March 2017 - 11:05 AM

Feng pretty well nailed it there. Yes, just increasing the persistence time beyond 20 mins (so, 25 mins would still be ok!) should fix your issue.

 

We generally say that you should use Source-IP persistence, as it works with ALL clients (and doesn't suffer the potential issue with Cookie Persistence of the default ver 0 cookies failing due to incorrect client time settings - yes, there are a couple of ways around that)



Christos Giotis Members

Christos Giotis
  • 5 posts

Posted 20 March 2017 - 01:34 PM

 

Receiver for Web (RfWeb) is session-based and requires sticky load balancing to ensure that requests during the http session are all directed to the same server. It is better to use cookie-insert LB persistence unless you have to support native Receiver for Android. If you have to use source ip LB persistence, you have to make sure that timeout is long enough for a typical RfWeb session. By default, RfWeb session times out after 20 minutes idle time. Please note that it is idle time, not fixed duration.

 

Feng thanks for your answer. So if i understood well in case off  sourceip  persistence LB option   the best practice to avoid  messages like "logon expired..." and "cannot complete your request" using sticky loadbalancing is  that in my configuration the persistance timeout should be equal to web session timeout.
For instance web session timeout = sourceip timeout =40min
Am i right ?

 



Christos Giotis Members

Christos Giotis
  • 5 posts

Posted 20 March 2017 - 01:53 PM

Feng pretty well nailed it there. Yes, just increasing the persistence time beyond 20 mins (so, 25 mins would still be ok!) should fix your issue.

 

We generally say that you should use Source-IP persistence, as it works with ALL clients (and doesn't suffer the potential issue with Cookie Persistence of the default ver 0 cookies failing due to incorrect client time settings - yes, there are a couple of ways around that)

Hi Paul,

I think is better that persistance timeout should be equal with web session timeout in order to use at the end of web session the  leastconnection LB algorithm. 

Do you agree?