Jeff, I only store three cookies: userReference, userid, password.
My experience is that these are the necessary and sufficient conditions to re-establish state. I want to distinguish state from path (any math majors out there? -- or thermodynamicists, ie., extensive vs. intensive properties). As long as each page view is a function of SEARCHARGs, POSTARGs and user authentication (which establishes the user's variable SET), you're okay. On the other hand, if you dribble bread crumbs as users traverse the site (meaning your app logic looks at some other user variables outside the base variable SET), then you won't be able to reconstruct the exact page the user was at. This of course can occur for example just before credit card processing begins. Say you set @@user$finalwarning=TRUE, and then the form action depends on finalwarning to begin. But I would expect a well structured app to trap this. (Or pass the parameter as a POST arg). But, it's just my opinion. > >Bill, > >I looked over your article on Scott's site. It looks like only username >and password are stored in cookies. Have you used this method to store >other user-scoped values? > >It seems you could modify an existing app to write any important >user-scoped values to cookies. The login code could then use <@VARNAMES >SCOPE="cookie"> to walk the user's saved values and re-assign them in >user-scope. (As long as you trust the cookie values.) > >That would certainly get around problems with writing/reading vars to/from >a file on the server. > >- Jeff > > >>I think the persistent login method I outlined on Scott's site will do >>this for you. (Note that I do it a little differently now). >> >>Essentially, this method allows users vars to timeout without requiring >>user action by making the server handle the re-creation of user variables >>behind the scenes. When the user authentication vars don't match the >>user authentication cookies, I redirect to the login process. If there >>are authentication cookies, then the login proceeds without a user >>prompt. If the cookies don't exist or don't authenticate properly a >>login prompt is presented. In either case, upon re-authentication, all >>user variables are re-established and then a re-direct to the originating >>page is invoked. >> >>Of course to have this work, one must save all POSTARGs as user-variables >>(thanks, John, for pointing me in this direction six months ago) and >>then use these user variables instead of POSTARGs. >> >>>The procautostart implementation is very clean and the nice thing about >>>it is that since it doesn't rely on cron (which at most runs once per >>>minute) it can be setup to check more frequently than that. The example >>>I sent earlier will restart the Witango server within 5 seconds of the >>>server going down. >>> >>>Except for user sessions getting lost, you wouldn't even know the server >>>crashed. >>> >>>Which brings me to another question. Is there a way to force the server >>>to cache user variables to disk (like it does when you do a clean >>>restart of the service) so that if I did that every minute or so, i'd >>>end up only loosing the users that haven't been on for that long? Of >>>course I'd only do it if it wasn't too cpu intensive. >>> >>>/John >>> >>>Jeff Bohmer wrote: >>> >>>>There are a few more options. In addition to procautostart, there is also >>>daemontools <http://cr.yp.to/daemontools.html>. >>>> >>>>I've been using the shell script below on OS X for a while. I also use >>>STARTUPURL to call a TAF that emails me when the app server starts. >>>> >>>>- Jeff >>>> >>>> >>>>#!/bin/sh >>>># >>>># watcher.sh >>>># >>>># Start the Witango app server if it isn't running. >>>># If the variable dump file exists, deleted it before >>>># starting the app server. >>>># >>>>. /etc/rc.common >>>> >>>>/usr/bin/top -w -l 1 | /usr/bin/grep witango >> >>>/Applications/Witango/Server/watcher.log >>>> >>>>x=`/bin/ps axc | /usr/bin/grep witango` >>>>if /bin/test -z "$x" >>>>then >>>> ConsoleMessage "watcher.sh: Starting Witango App Server" >>>> echo "`date` watcher.sh: Starting Witango App Server" >> >>>/Applications/Witango/Server/watcher.log >>>> if /bin/test -e >>>/Applications/Witango/Server/configuration/variables.WitangoServer/Witango >>>Server.dump >>>> then >>>> rm >>>/Applications/Witango/Server/configuration/variables.WitangoServer/Witango >>>Server.dump >>>> fi >>>> /Library/StartupItems/Witango5/Witango5 start >>>>fi >>>> >>>> >>>> >>>> >>>> >>>> >>>>>The solution that I implemented on Linux should work on OSX... No need to >>use >>>cron though. >>>>> >>>>>the solution i used is called "procautostart" >>>>> >>>>>I downloaded the source and compiled it. Since OSX is a flavor of Unix >>now, >>>you should be able to do the same. >>>>> >>>>>Check out this link, it explaines how the procautostart process works. >>>>> >>>>>http://www.linuxdocs.org/HOWTOs/Process-Monitor-HOWTO-2.html >>>>> >>>>>Once you get procautostart compiled and running on the simple test that >>they >>>provide, you can do something like this to your start witango script. >> >>> >>>>>#!/bin/bash >>>>> >>>>># Set up environment >>>>>umask 022 >>>>>WITANGO_USER=witango ; export WITANGO_USER >>>>>WITANGO_PATH=/usr/local/witango ; export WITANGO_PATH >>>>>WITANGO_CONFIG=$WITANGO_PATH/configuration ; export WITANGO_CONFIG >>>>>JAVA_HOME=/usr/local/j2re1.4.1_03 ; export JAVA_HOME >>>>> >>>>>PATH=$WITANGO_PATH/bin:/bin:/usr/bin ; export PATH >>>>>LD_LIBRARY_PATH=$WITANGO_PATH:$JAVA_HOME/lib/i386/server:$JAVA_HOME/lib/i38 6/ >>cl >>>ient:$JAVA_HOME/lib/i386:/usr/lib ; export LD_LIBRARY_PATH >>>>>CLASSPATH=$WITANGO_PATH/jdbc_drivers/JSQLConnect.jar:$WITANGO_PATH ; export >>>CLASSPATH >>>>>LC_ALL=en_US ; export LC_ALL >>>>> >>>>>cd /usr/local/witango >>>>> >>>>>/sbin/procautostart -n 5 -c "$WITANGO_PATH/witangod -u" nohup & >>>>> >>>>> >>>>>/John >>>>> >>>>>Michael Dittbrenner wrote: >>>>> >>>>> >>>>> >>>>>I was wondering if anyone has and is willing to share code to have the >>witangod� >>>process restarted after it unexpectedly quits. We just upgraded to witango >>>5 for mac and the server seems to quit out, I was in the process of trying >>>to write a shell script to be called by crontab to see if the process is >>>running if not to start it. If someone has anything like this and is >>>willing to share I would greatly appreciate it. >>>>> >>>>> >>>>>Mike D >>>>> >>>>> >>>>>**************************************** >>>>> >>>>>Educational Directories Unlimited, Inc. >>>>> >>>>> >>>>>Michael Dittbrenner >>>>> >>>>>Programmer >>>>> >>>>>http://www.StudyAbroad.com <http://www.studyabroad.com/> >>>>> >>>>>http://www.GradSchools.com <http://www.gradschools.com/> >>>>> >>>>>A service of EDU, Inc... http://www.EDUdirectories.com >>><http://www.edudirectories.com/> >>>>> >>>>>A partner of EDU Internet Strategies: >>http://www.EDUInternetStrategies.com/ >>><http://www.eduinternetstrategies.com/> >>>>> >>>>> >>>>>[Phone] 610-499-9200 >>>>> >>>>>[Fax] 610-499-9205 >>>>> >>>>>[E-mail] [EMAIL PROTECTED] or [EMAIL PROTECTED] >>>>> >>>>> >>>> >>>> >>>> >>> >>>________________________________________________________________________ >>>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >> >> >>Bill Conlon >> >>To the Point >>345 California Avenue Suite 2 >>Palo Alto, CA 94306 >> >>office: 650.327.2175 >>fax: 650.329.8335 >>mobile: 650.906.9929 >>e-mail: mailto:[EMAIL PROTECTED] >>web: http://www.tothept.com >> >> >>________________________________________________________________________ >>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > >-- > >Jeff Bohmer >VisionLink, Inc. >_________________________________ >303.402.0170 >www.visionlink.org >_________________________________ >People. Tools. Change. Community. >________________________________________________________________________ >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > Bill Conlon To the Point 345 California Avenue Suite 2 Palo Alto, CA 94306 office: 650.327.2175 fax: 650.329.8335 mobile: 650.906.9929 e-mail: mailto:[EMAIL PROTECTED] web: http://www.tothept.com ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
