Hopefully somebody can assist me with troubleshooting a web application I have to publish via UAG. The application in question is our HR portal, a product called 'HR21' by Frontier.
I have tried publishing the application with 'application specific hostname' and 'portal hostname', both with the same result. Initially when publishing the application, it behaved very oddly and I realised this was due to UAG's cookie handling. Having established the cookies used by the application, I have created a custom WhlFiltSecureRemote_HTTPS.xml and rectified this particular problem.
However, although you can now log into the application, when selecting any page from the menu structure, it is as if the page never fully finishes loading. Although the relevant data is displayed (this is a HR application, so say for example a page for 'annual leave history'), the page is greyed and a spinning progress indicator is displayed. This never times out. At this point, I can press the browser's back button, which forces me to log in again, and select the same menu item, the page then displays correctly. However, any further menu items selected result in the same behaviour.
I appreciate that without seeing the application of the behaviour this could be difficult to answer. I am very new to UAG and I'm not sure how to troubleshoot this or proceed further. I have investigated traffic using Fiddler but I am not really too sure what to look for.
Thanks for your response. The application is called HR21 by a company called Frontier. I cannot post a link as the forum will not let me, however Google will find it if needs be.
The contents of the WhlFiltSecureRemote_HTTPS.xml file are as follows:
How should I go about sharing the Fiddler file? Again, the forum will not let me post a link and I can't see a way of attaching files.
I do not know, how you concluded that this might be because of cookie handling, however I have had a look on the fiddler logs and I could not see the SRA taking effect - you have created a SRA by the name WhlFiltSecureRemote_HTTPS.xml, so as UAG will NOT sign those cookies mentioned.! BUT if you look at the the cookie names still they are signed (you should be able to read the cookie names and not junk values if they are unsigned)
this could be because of multiple things, but you can start off with this.
1. verify that you have the app type exactly as you specified in step 2 (Configure Application)<APPLICATION_TYPE>Ajax</APPLICATION_TYPE>2. You have SRA in correct place <UAG Path>\von\conf\websites\<trunk>\conf\CustomUpdate3. You have activated your UAG after placing this.4. You have this file in all of your UAG nodes.5. If required IISRESET in all your UAG boxes
Also confirm the cookie names and correct and you have included all the cookies that app would set - to confirm this you can take HTTPWatch logs when you are connected Directly to webserver
- Proposed as answer by Vasu Deva Tuesday, July 02, 2013 7:19 PM
Prior to creating the WhlFiltSecureRemote_HTTPS.xml file, the application would not even allow a login. When pressing the logon button, it would briefly flash the main page and then return to the logon window again. I used Fiddler when connected directly to the webserver to determine the two cookies used (confirmed this by watching the cookie handling within Google Chrome- the names of the two cookies matched those I obtained with Fiddler) and added them to the file. .ASPXAUTH and ASP.NET_SessionId are the two cookie names.
After doing this, placing the file in the correct location as you mention below, and activating the config, I can now log in successfully. So I presume the WhlFiltSecureRemote_HTTPS.xml file must be doing something. However, I now have the problem of the ‘infinite loop’ type symptoms.
I have tested this with Chrome, IE9 and IE10 and the results are the same. If I press escape when the indicator is spinning, the spinning does stop but the page remain ‘greyed over’ and the spinning icon is still there- just stopped. I have attached httpwatch logs for both direct connection (hr21direct.hwl) and via UAG (hr21.hwl) to an email which you should now have, which may help?
Please note that although I have tested previously using portal hostname, I AM currently using Application Specific Hostname template. These logs relate to this method.