Re: Checking if cookies enabled
Another possibility without using any JavaScript, thus independent from the JS settings of the user is: DTML method cookieTest: <dtml-call "RESPONSE.setCookie('cookiesAllowed', 'yes')"> <html><head> <meta http-equiv="refresh" content="0; URL=cookieTestComplete"> </head> <body> <a href="cookieTestComplete">Redirecting to cookieTestComplete...</a> <dtml-var standard_html_footer> DTML method cookieTestComplete: <dtml-var standard_html_header> <dtml-if "REQUEST.cookies.has_key('cookiesAllowed')"> <h1>Cookies are allowed!</h1> <dtml-else> <h1>Cookies are not allowed!</h1> </dtml-if> <dtml-call "RESPONSE.expireCookie('cookiesAllowed')"> <dtml-var standard_html_footer> Successfully tested with NS 4.78, IE 5.0. There could perhaps be problems if the users has (somehow) turned off auto-redirecting... That's why there is the link left in cookieTest. -- Lars Heber, mailto:Lars.Heber@t-systems.de T-Systems, debis Systemhaus GEI GmbH, Geschaeftsstelle Sachsen
On Sat, 24 Nov 2001, Lars Heber wrote:
Another possibility without using any JavaScript, thus independent from the JS settings of the user is:
DTML method cookieTest:
<dtml-call "RESPONSE.setCookie('cookiesAllowed', 'yes')"> <html><head> <meta http-equiv="refresh" content="0; URL=cookieTestComplete"> </head> <body> <a href="cookieTestComplete">Redirecting to cookieTestComplete...</a> <dtml-var standard_html_footer> Something about cookies in general: I'm bothered by cookies and so I made my cookies file a symbolic link to /dev/null. This works perfectly with Zope but you can't relay on reading out cookies for sure. By the way, several sites which claim to require cookies work with this settings and I do not have to clean up regularly my cookies file :).
Kind regards Andreas.
On Tue, Nov 27, 2001 at 12:38:43PM +0100, Tille, Andreas wrote:
Something about cookies in general: I'm bothered by cookies and so I made my cookies file a symbolic link to /dev/null. This works perfectly with Zope but you can't relay on reading out cookies for sure. By the way, several sites which claim to require cookies work with this settings and I do not have to clean up regularly my cookies file :).
The better solution is to use a filtering proxy. (I cannot get rid of cookies completely, as I often login to sites, such as web-based email, etc.) With a filtering proxy you can control black and white lists to your preferences. BTW, Mozilla browser maintains lists of sites to disallow cookies and images. Simple and easy, but powerful protection. Oleg. -- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Tue, 27 Nov 2001, Oleg Broytmann wrote:
The better solution is to use a filtering proxy. (I cannot get rid of cookies completely, as I often login to sites, such as web-based email, etc.) With a filtering proxy you can control black and white lists to your preferences. BTW, Mozilla browser maintains lists of sites to disallow cookies and images. Simple and easy, but powerful protection. I know about this mozilla feature, but the /dev/null link is easiest to install works for every browser and works well for me.
I just wanted to notice that the cookie test might fail for some reasons ... Kind regards Andreas.
At 12:52 24/11/2001 +0100, Lars Heber wrote:
Another possibility without using any JavaScript, thus independent from the JS settings of the user is:
DTML method cookieTest:
<dtml-call "RESPONSE.setCookie('cookiesAllowed', 'yes')"> <html><head> <meta http-equiv="refresh" content="0; URL=cookieTestComplete"> </head> <body> <a href="cookieTestComplete">Redirecting to cookieTestComplete...</a> <dtml-var standard_html_footer>
Neat. This is much better that relying on Javascript and the user's settings for it. Alternatively you could say: <dtml-call "RESPONSE.setCookie('cookiesAllowed', 'yes', path='your-protected-path', domain='your-server')"> <dtml-call "RESPONSE.redirect('whichever-URL-you-want-to-end-up-at', status=302)"> The only advantage of this over the original suggestion is that some (probably ancient) browsers may not support and correctly interpret the META HTTP-EQUIV whereas the HTTP 302 redirect response is unlikely to fail on any browser.
participants (4)
-
Lars Heber -
Oleg Broytmann -
Richard Barrett -
Tille, Andreas