home about contact feed
vagra vaBlo
C++(7) Solaris(4) tntnet(3) vi(3) Linux(2) DeleGate(2) Postgres(2) proxy(2) cxxtools(1) regex(1) readline(1) dtrace(1) gcc(1) MeeGo(1) ssh(1) firefox(1)

how to check if the client does accept cookies in tntnet

cookie check in tntnet

Tntnet uses session cookies for keeping track of the client if there are variables defined in the <%session> scope. However, if you rely on clients accepting and sending cookies, you application might work erronous.

For example you could redirect the client to a login page, if there is no valid session set. If the client does not accept cookies, it would end in a redirection loop until the client detects the loop, stops sending requests and displays an inconvenient error page.

To fix that, you could enable some JavaScript to test if the client has cookies enabled, however this would not work for these clients, who doesn't have JavaScript enabled and also would most likely ignore exceptions the user might want to set just for you.

A better way is to check the cookie support with a redirect, here is an example for tntnet:

<%session scope="global">
  bool cookies = false;
  bool redirected = false;
  std::string orig_query;
    if(request.getQueryString() == "cookietest")
    orig_query = request.getQuery();
    cookies = true;
  if (!redirected)
    redirected = true;

First it checks if the cookie variable is set to false, if so it checks if the URL parameter is "cookietest" which the test would set later. If cookietest is the url parameter, it's safe to assume, that the browser has been redirected before and therefore will redirect the client to "/error/nocookie" which can deliver an appropriate error message

If the cookie variable is false and the url parameter is not "cookietest", it will store the original request in orig_query, set cookie to true and redirects to the testpage.

If the cookie variable is true, cookies are enabled and it's save to redirect to the original Page. To prevent a redirection loop when the original url will for what ever reasons cause the test again, we also set redirected to true

Write comment