Does SWGFL proxy cache cookies?

[JAB1a]

Hi All,

 

This might be a silly question but I will ask anyway and give the reason.

 

Last week I had about 20 users all trying to access a https site using different usernames etc (it was for Thrive training). They said that if one person tried to add a record to the system logged on as 'user1' while someone else in the suite (logged on as 'user2') tried to access another page they were not on then they would then be presented with the page as if they were 'User1'..... I am sure that still does not make sense after reading it 5 times so I will right it in steps

 

Both users are using IE10 and logged onto the Thrive site as...

1.PC1 is logged on as 'User1'

2.PC2 is logged on as 'User2'

3.User1 adds a record to Thrive and saves

4.User2 refreshes Thrive page on PC2 and it now says they are logged in as 'User1' (they should be 'User2')

 

eMy question is...

 

Does SWGFL proxy cache cookies or something that would cause this issue to happen? I ask because this is a idea put forward by the programmer's of the software, they think I need to disable the cache on the proxy. If that is what is needed then why didn't Merlin and all other content management systems fall foul of this issue?

 

I hope someone can make sense of this and give an answer

 

Thanks for your time and effort in advance

[JAB1a]

Bump for an answer if possible

[TheScarfedOne]

*bump for Julia @SWGfL_Official

[imullings]

Sounds like the website is using the IP address once logged in. SWGFL and most proxy servers present connections as if they are the same IP. SWGFL run several proxies but it will still cause clashes.

Hope that makes sense and helps the programmer sort out the issue.

 

Ian Mullings

Devizes School IT Support

[JAB1a]

Thanks for your help guy's. I am not up on how their website works but they said it all works off Tokens? I mentioned that maybe its because externally the 2 PC's will most probably appear to have the same IP to their servers but they said that would not matter (due to the tokens?).

 

I have been unable to recreate the situation myself so I am finding hard to work out how this can happen, basically I am trying to make sure its not something to do with our system in the school.

[Meldrew]

I wonder if part of their token is the IP address...? Might be worth loading the debug console on your browser when the site is loaded and look for this token in the cookies. Then do the same on a user 2 and see if anything jumps out at you.

 

Meldrew

[SWGfL_Official]

Hi,

 

I've had a chat with our engineers and have the following update:

 

The proxies are configured not to cache anything, but this is a moot point given that access is via HTTPS.

 

With HTTPS the proxies act like a firewall with NAT in that the client workstation's IP address is hidden behind the IP address of the proxy, but the proxy doesn't otherwise touch the data. The same applies with transparent filtering.

 

Are you using a local caching device? But even then it's unlikely that it busts HTTPS and caches the data. HTTPS is implicitly non-cacheable.

 

It may be worth investigating a possible application issue.

 

 

I hope this is helpful,

 

Thanks Julia

[JAB1a]

Thank you so much for this reply @SWGfL_Official (Julia)

 

That is the kind of information I needed to go back to the developers (application guys) with, I had not even thought about https not being cached to start with.

 

I will let you know what they come back with, if anything.

 

Thank you for your time and effort