Forum Discussion

sergio_baza_alo's avatar
sergio_baza_alo
Icon for Altocumulus rankAltocumulus
May 14, 2018

Why the page /my.policy redirects users to /vdesk/hangup.php3 ?

Hello all,

 

I have a problem with the APM, I have an application published and sometimes the users are unable to see the login page, instead of that they get the logout page.

 

This is very strange because it doesn't happens all the times, only sometimes so for me this seems a cookie problem or something like that.

 

I've been using the fiddler tool and I've seen that sometimes when the my.policy URL is called the F5 closes the connection and redirect the user to /vdesk/hangup.php3, also in the same GET I see the session cookies and it seems to be ok.

 

There is no iRules that redirects the request to /vdesk/hangup.php3 and I've not modified the logon page code.

 

Do you know why could this be happening?

 

 

8 Replies

  • Hi Sergio,

     

    For information, vdesk/hangup.php3 is a script deleting a user's session (remove cookie regarding your session).

     

    You can be redirect to vdesk/hangup.php3 when you don't pass the policy (VPE).

     

    Did you check the report ? in order to see why the user is logged out.

     

    Last point you have 2 differente type of loggout using vdesk/hangup.php3.

     

    • when user trigged a logout.
    • when your fail apm policy (and in this case, you will find your session ID)...

    Regards

     

  • Dear,

     

    You have to look into the /var/log/apm log file and eventually enable debug logging level to see the details when this issue occur.

     

    regards.

     

  • Hi,

     

    it is not recommended to insert any box between Logon page and Auth boxes.

     

    I know it was required before Radius to change session.logon.last.password. I say was because in version 13.1 (I'm not sure which version add this feature) you can configure the password source.

     

    Why isn't it recommended to insert a box between logon page and Auth? because these boxes are evaluated only once. if the first user authentication attempt fails, all following attempts will be evaluated within the AD auth box, there is no rollback in the decision tree to the logon page.

     

    Then iRule event is not recommended. I know you find this one in an article from a F5 employee written in 2013. Everything that can be done with variable assign may be done with variable assign. irule event requires an external execution of code from access profile which add evaluation latency and variable cache issues.

     

    here are variable assign expressions you can use instead of irules (use this variable assign order because flags expression uses trusted value)

     

    session.custom.owa.trusted =

     

    expr {[mcget {session.logon.last.pubpriv}] == "private" ? 4 : 0}
    

    session.custom.owa.flags =

     

    expr {[mcget {session.logon.last.lightversion}] == "yes" ? [mcget {session.custom.owa.trusted}]+1 : [mcget {session.custom.owa.trusted}] }
    

    Even if you use irule event or the variable assign I provide, move all sso to the end of the decision tree. these variables are not required for authentication but only for SSO.

     

  • Hi Sergio, Did you manage to get this issue fixed. I have a Customer reporting the same issue on F5 AWS - Version 12.1.1 HF1. Thank you,

     

  • Hi Sergio, Did you manage to get this issue fixed. I have a Customer reporting the same issue on F5 AWS - Version 12.1.1 HF1. Thank you,

     

    • sergio_baza_alo's avatar
      sergio_baza_alo
      Icon for Altocumulus rankAltocumulus

      Hi Sathya, it seems that version 12 has some kind of problems with the session management. We resolved the problem by updating to version 13.1.0.8 In this version everything works much better, I would recommend you to update yor F5. Regards