> > > > > > > > -----Original Message----- > > > > > From: Randal L. Schwartz [mailto:[EMAIL PROTECTED] > > > > > Sent: Thursday, September 04, 2003 12:33 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: Test if browser's allows cookies/has them turned > > > > > onetc.. > > > > > > > > > > > > > > > >>>>> "Dan" == Dan Muey <[EMAIL PROTECTED]> writes: > > > > > > > > > > Dan> As much as I hate to do stuff that requires cookies, > > > there is a > > > > > Dan> project I'm doing that requires cookies. > > > > > > > > > > This should have been on [EMAIL PROTECTED] instead. More > > > > > experts there about this stuff. > > > > > > > > > > Having said that, you should read my "basic cookie management" > > > > > column at > > > > > <http://www.stonehenge.com/merlyn/WebTechniques/col61.html>. > > > > > > > > > I'm told that code was made into a module, but I can't > > > seem to find > > > > > that reference now. > > > > > > > > Cool, that's pretty much the method I was using so I > guess I'm not > > > > crazy! I agree with your sentiments about cookies in > the article. I > > > > try to avoid them when ever possible but this one app > will require > > > > them, either that or I have to make sure the data is passed > > > in every > > > > invokation of the script via link or form which might just be > > > > worth > > > > the trouble. > > > > > > YES!! It definitely is worth the trouble, and it is not that > > > much trouble, if your routing is well-designed. I haven't > > > used the CGI module much, but I can tell you that <input > > > type="hidden" name="info_tag" value="whatever is currently > > > useful for this stage"> works quite well, and should be > > > returned as $cgi_object->param{'nfo_tag'}. > > > > > > Much better than playing with your audience's file system. > > > > > > > True, the only thing I can't seem to do is this: > > > > Say you have super duper shopping system, that passes > > shopperid=123456 around in every single form and link so that their > > cart and whatever info 123456 refers to is available. > > > > Now how can you have a link to the shopping cart from a static page > > unrelated to the cart, or what if your shopper leaves the site for > > soemthign else and comes back, or how could they shut their browser > > down and restart up again, all of those situations and still keep > > their info all along? > > > > Perhaps, pass the number around and if it is not > available(IE one of > > the above situatios) check for a cookie and if there is no > cookie try > > to set one and simply tell them they need cookies for their > session to > > be remembered? > > > > Cool? > > Dan, > > Ever looked at HTML::Mason? Check out this article on how to > display and hide session variables using httpd.conf (in > conjunction with HTML::Mason of course). It's a great > templating engine that runs on top of mod_perl. > > http://www.masonhq.com/user/adpacifico/ApacheSessionMason.html#uri%20tricks%20and%20mysql
> Also, the Mason Book is available online at http://www.masonbook.com > HTH, Thanks for the idea, I'll look into it. I'm a bit leary of it though since the average Joe would have a hard time just ftping, chmoding, and running it. And if I'm not mistaken after they close their browser their data will be gone when they next open their browser, correct? If that's the case it seems like a lot less trouble to just pass the userid=123456 param around since you still have the sam eproblem of remembering them thet nect time they turn their computer on. Don't get me wrong I hat cookies too and definitely am aware of the security issues, I'm just trying to find a way to remember them if possible over multiple sessions. Without them having to log on. Thanks for the info! Dan -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
