Forum Discussion

diamond's avatar
Icon for Altostratus rankAltostratus
Nov 02, 2023

Added Internal site on F5 Webtop, now it mixes user accounts

Hi, I have internal booking website "x", which works properly when I access it directly.

I have added it in F5 webtop portal for remote users. 

When remote user accesses the website and logs in with he's user, the portal or website (idk which) mixes user accounts, that is when user Y logs in from webtop, it may actually login a user Z using user T's credentials.

I'm not sure if our website X has problem itself or it is webtops fault.

Plesae suggest me something if you know this problem.


Thanks, Diamond.

7 Replies

  • These kinds of problems can be frustrating. Issues like this where one user logs in and sees another user's info is often due to caching. BIG-IP can store web responses from servers to speed access from users. Normally the web app server sends a "don't store this content!" signal to indicate that it is private, but sometimes this can be trouble with it. Review this article to adjust the BIG-IP's caching:

    Another caching mechanism exists within web browsers themselves and can lead to similar symptoms. If it's the case that you have two users logging into the *same* browser and they see each-other's content, try to disable the browser's web cache. This Stack Overflow article discusses how to do that:


    If neither of those is the trouble, your best bet is probably to open a support ticket:


    • diamond's avatar
      Icon for Altostratus rankAltostratus

      Hi, what do you recommend with the caching? should we change some settings / disable it or what configuration should we try?


  • diamond , I need some details 🙂

    Are you using Portal Access resource type, or Webtop Link resource type ?

    If users are mixed up, it means the application is trusting an IP or HTTP element which is common between the 2 APM sessions. We need to know how the Application assign a session to a user.

    It can be based on an cookie, header, or something else (tcp session). 

    First advice : disable "one-connect" if it is enabled.

    • diamond's avatar
      Icon for Altostratus rankAltostratus

      Hi Matt, 

      I'm support technician and I can't get the info from the admins to tell you unfortunatelly.

      They tell me that it has nothing to do with webtop and the site's dev also tells me it's not sites problem.

      I don't know but it can be website X's fault, as it lets you login using Y's credentials and then in portal it allows to see user Z's information. (doesn't this looks like the site has vulnerability?)

      I upload images for more info. As you can see, 1st image, user INGA is loged in in her portal, then she wants to open"family doctor" page to see her patients and when she opens it, the 2nd page opens and it shows user DADIANIDZE's page actually and her patients.   

      Does it looks like f5 webtops problem or the internal site's problem? I repeat, internal website works good with cisco anyconnect and directly. the issue is only with when the users logs in with from F5 webtop portal.


      Lucas_Thompson Lucas_Thompson, thanks for your info. I hope I get proper information to the admins.

  • Hi Diamond, because caching can cause behavior like you describe, I'd recommend disabling the cache (BIG-IP's and the browser's) temporarily to test if this is causing the bad behavior. If you're unfarmiliar with caching, please read this article:

    If you are using Portal Access  (please read this article to understand what it is , then try using the "no cache" setting, also explained in that article.

  • lylawa's avatar
    Icon for Nimbostratus rankNimbostratus

    Are you utilizing the Portal Access resource type or the Webtop Link resource type?

    If users are getting mixed up, it indicates that the application is relying on an IP or HTTP element common between the two APM sessions. It's crucial to understand how the application assigns a session to a user, whether it's based on a cookie, header, or another factor like TCP session.

    As an initial step, consider disabling "one-connect" if it's currently enabled.