locked
UAG Application specific hostname application with a session cookie with the original domain RRS feed

  • Question

  • Hi,

    I have had and externally hosted library catalogue published as a UAG portal hostname application for some time but due to all java and required appwrap & SAR to get it working I wanted to convert it to an application specific hostname so I won't have to change them every time the application gets updated/changed.

    Everything seems to work when its published except for login due to a session cookie issue.

    A login form posts and returns a session cookie from the server successfully and redirects to the correct page but the domain of the cookie is set as the external server domain name not the public name of the application i.e app.external.com rather than app.uni.ac.uk other cookies from the application have the correct domain.

    As the domain doesn't match when the application check if you are logged in you get kicked back to login again and into an endless loop, if I edit the cookie in the browser to the uag application domain as expected I get treated as logged in.

    I have seen a few examples of cookie handling using WhlFiltSecureRemote_HTTPS but it doesn't seem to have any effect on the cookie.

    I have tried matching on server name and by application as below:

    <COOKIES_HANDLING>
    <SERVER>
    <SERVER_NAME mask="">app\.external\.com</SERVER_NAME>
    <NAME>session</NAME>
    <Domain remove="true">WHL_SERVER_NAME</Domain>
    </Set-Cookie>
    </SERVER>
    </COOKIES_HANDLING>

    or

    <COOKIES_HANDLING>
    <SERVER>
    <SERVER_NAME mask="">.*</SERVER_NAME>
    <NAME>session</NAME>
    <Domain>app.uni.ac.uk</Domain>
    </Set-Cookie>
    </SERVER>
    </COOKIES_HANDLING>

    or

    <COOKIES_HANDLING>
        <APPLICATION>
            <APPLICATION_TYPE>ApplicationTypeName</APPLICATION_TYPE>
            <Set-Cookie>
                <NAME>session</NAME>
                <Domain>app.uni.ac.uk</Domain>
            </Set-Cookie>
        </APPLICATION>
    </COOKIES_HANDLING>

    and several variation in between, obviously I must be doing something wrong, I have removed all my other entries from WhlFiltSecureRemote_HTTPS and there are no obvious syntax errors(opened in IE etc.) but it seems to have no effect on this cookie.

    Any advice and suggestions very welcome.

    Thanks,

    Ged

    Additional info looking through the trace file the "session" cookie seems to be the only one completely ignored by UAG I can see it process the other cookies on the site, is seems this cookie is passed straight through to the browser without being touched by UAG.

    Going through the trace a bit more it seems to be handling the server header response set-cookie as an URL (cookie name and value in bold for the login):

    [0]760.1610 06/14/2012-15:07:52.986 [whlfiltsecureremote CServerScrambling::SignAbsoluteURLForGivenServers ServerScrambling.cpp@782] Info:SignAbsoluteURLForGivenServers for URL session

    [0]760.1610 06/14/2012-15:07:52.986 [whlfiltsecureremote CServerScrambling::SignAbsoluteURLForGivenServers ServerScrambling.cpp@787] Info:SignAbsoluteURLForGivenServers(session): did not recognize scheme, probably relative URL

    [0]760.1610 06/14/2012-15:07:52.986 [whlfiltsecureremote CServerScrambling::SignAbsoluteURLForGivenServers ServerScrambling.cpp@782] Info:SignAbsoluteURLForGivenServers for URL YTAxZDM5YjRjNjYyYmNmMzRiNmFiMzYzMjE4NDRiNjVhNDZkNTFhZTdhOTNjZmFmYTBiY2FjZmZiNmE5Y2UzOZfCu6LlIcFx2R5n5VT650YtvIyI8Wickcy%2F2Yf77vs0Btmivdr9iXjY9fKYATpVCRcGr0pGDksUAQlfvTQ7Sp8qI5JQC%2B8w9rveRJhdEYr5jtbRVmNmZ%2FUMuwApL6Nu7Dbaj9Tu%2BACEpmkDktksBzLZjqyTg7BkLSfggKH%2BVCQAa%2FOVlXuCXpxk9AFVMUV%2F9IVw%2BN74TKU6ImiBkTVX2y9NNQa311x8uZJOhrq7RtbR5jYGimUniZ7oicTKe7vXg562Hb6UdMMiREo0%2F51hVYBxZMZYcX64Y4yAeP9RfMkSIZ6XxuRLEWnuZoEMyxxbS26XWV%2BpWe%2FOHg8e6DOQvqYzWp7PPdk9Ki0aW9FZWgXz0Y6qGqFiiAFlm1Yi5fE%2FMXUiplEuHXwhVzs3YdPUxlNZKD%2BqTJbCXctf1R0MrDk1

    [0]760.1610 06/14/2012-15:07:52.986 [whlfiltsecureremote CServerScrambling::SignAbsoluteURLForGivenServers ServerScrambling.cpp@787] Info:SignAbsoluteURLForGivenServers(YTAxZDM5YjRjNjYyYmNmMzRiNmFiMzYzMjE4NDRiNjVhNDZkNTFhZTdhOTNjZmFmYTBiY2FjZmZiNmE5Y2UzOZfCu6LlIcFx2R5n5VT650YtvIyI8Wickcy%2F2Yf77vs0Btmivdr9iXjY9fKYATpVCRcGr0pGDksUAQlfvTQ7Sp8qI5JQC%2B8w9rveRJhdEYr5jtbRVmNmZ%2FUMuwApL6Nu7Dbaj9Tu%2BACEpmkDktksBzLZjqyTg7BkLSfggKH%2BVCQAa%2FOVlXuCXpxk9AFVMUV%2F9IVw%2BN74TKU6ImiBkTVX2y9NNQa311x8uZJOhrq7RtbR5jYGimUniZ7oicTKe7vXg562Hb6UdMMiREo0%2F51hVYBxZMZYcX64Y4yAeP9RfMkSIZ6XxuRLEWnuZoEMyxxbS26XWV%2BpWe%2FOHg8e6DOQvqYzWp7PPdk9Ki0aW9FZWgXz0Y6qGqFiiAFlm1Yi5fE%2FMXUiplEuHXwhVzs3YdPUxlNZKD%2BqTJbCXctf1R0MrDk1): did not recognize scheme, probably relative URL
    Unknown( 52): GUID=3375ea49-24d8-999e-4c20-34f9df4fdba4 (No Format Information found).
    Unknown( 14): GUID=3375ea49-24d8-999e-4c20-34f9df4fdba4 (No Format Information found).

    [0]760.1610 06/14/2012-15:07:52.986 [whlfiltsecureremote CConfigurationGeneral::GetParserConfigForAppTypeInternal ConfigurationGeneral.cpp@1028] Info:No libapp application specific parsers configuration found, using default parsers configuration
    Unknown( 15): GUID=3375ea49-24d8-999e-4c20-34f9df4fdba4 (No Format Information found).

    So is there any way to get UAG to recognise this response correctly?

    Or is this due to me having to use the replace header option on the web server tab, unfortunately as this is an external hosted service I have no control over the backend server configuration and have to use this option to get the it to work?

    Thanks,



    • Edited by Ged_Attwood Thursday, June 14, 2012 3:16 PM
    Wednesday, June 13, 2012 10:54 PM