Forum Discussion

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 13, 2012
    Cookie detection is usually left to client side Javascript and the browser's Document Object Model. Here's just one example of many for doing this: https://github.com/Modernizr/Modernizr/issues/191.

     

     

    The problem with performing this test server side is twofold: you have to set a cookie and see if it gets returned, and also maintain some persistence mechanism OTHER THAN cookies while testing. So a legitimate code example for your request depends on:

     

     

    1. what you can use for persistence if cookies aren't supported (source IP, SSL session ID, etc.)

     

    2. what you would do if cookies are disabled (terminate the session, manipulate the URI, etc.)

     

     

    In case you just want to close the connection and let them know the site requires cookies, the following may work for you:

     

     

    
when HTTP_REQUEST {
if { ( [HTTP::uri] starts_with "/cookietest" ) } {
 test for cookie
if { not ( [HTTP::cookie exists "COOKIETEST"] ) } {
 cookies are disabled
HTTP::respond 200 content "Sorry. This site requires cookies"
} else {
 cookies enabled - redirect to first URI
HTTP::respond 302 Location [findstr [HTTP::uri] "/cookietest" 11]
}
} elseif { [HTTP::cookie count] == "" } {
 no cookies (could be first request) - redirect to cookie test URI with test cookie
HTTP::respond 302 Location "/cookietest[HTTP::uri]" "Set-Cookie" "COOKIETEST=1"
}
}

     

     

  • Pradeep_Kandala's avatar
    Pradeep_Kandala
    Icon for Nimbostratus rankNimbostratus
    Sep 13, 2012

    It means I need to write a code under cookietest for cookie checking ?? and iRules dosn't have any directly ryt ??

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 13, 2012
    The problem is really WHERE you're doing the checking. JavaScript on the client side has direct access to the Document Object Model. From the BIG-IP, or ANY server side language, you have to perform a remote test - send a cookie and see if it gets returned. Plus, the stateless nature of HTTP requires that you have some mechanism, in this case other than cookies, to track a specific request/user process. If you send the user a cookie as part of your test, but don't have a way to identify that user as a returning request, you could end up in a loop. The above code very simply uses the /cookietest URI as the persistence mechanism. If you needed to allow users to access without cookie support, you'd need to build in another persistence/session tracking mechanism - like source address or query string.