Re: Cookies again: Expiry Date

2010-09-06 Thread Gregory Lypny
Hi Stephen,

Just to add to Andre's tip, I've found the setting and getting of cookies to be 
extremely finicky.  One thing that tripped me up for about four hours was the 
placement of ?rev in scripts.  It must appear in the very first line of any 
script involving cookies.  Leave a blank first line, and it is possible that 
everything in a script will work except for things having to do with cookies!

Regards,

Gregory


On Sun, Sep 5, 2010, at 11:04 PM, use-revolution-requ...@lists.runrev.com wrote:

 Message: 13
 Date: Sun, 5 Sep 2010 14:46:20 -0700
 From: stephen barncard stephenrevoluti...@barncard.com
 Subject: Re: Cookies again: Expiry Date
 To: How to use Revolution use-revolution@lists.runrev.com
 Message-ID:
   aanlkti=zd=cjwf5u3u-6c6zvygxxoepyl7feg=4hc...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8
 
 That was it. The date format.  Thanks very much, Andre.
 
 sqb

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-06 Thread Jeff Massung
On Sun, Sep 5, 2010 at 4:46 PM, stephen barncard 
stephenrevoluti...@barncard.com wrote:

 That was it. The date format.  Thanks very much, Andre.


Stephen,

I don't know what you are using this particular cookie for, but just thought
I'd comment on something for everyone else following the thread...

If you are dealing with logins and using a cookie for that, I find it is
usually bad practice to use an expired cookie for that as opposed to
handling the expire server-side: typically within the database itself, and
letting the cookie just be a unique identifier that tells the server what
row in the database to be looking at. It makes the cookie cleaner and is
more secure.

Jeff M.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-06 Thread Andre Garzia
On Mon, Sep 6, 2010 at 1:36 PM, Gregory Lypny
gregory.ly...@videotron.ca wrote:
 Hi Stephen,

 Just to add to Andre's tip, I've found the setting and getting of cookies to 
 be extremely finicky.  One thing that tripped me up for about four hours was 
 the placement of ?rev in scripts.  It must appear in the very first line of 
 any script involving cookies.  Leave a blank first line, and it is possible 
 that everything in a script will work except for things having to do with 
 cookies!


Gregory,

That is not an actual bug but a design behaviour. RevServer engine
will output things as soon as it can, meaning that the blank line will
be sent as is back to apache server as soon as your script starts
executing. HTTP Headers must be sent to apache before actual output is
sent, so if you have a blank line on top of your file, that is treated
by the engine as hey you want to output a blank line, fine! and thus
all the subsequent put header calls will fail since apache will pick
that blank line and start outputing everyting as content and not as
headers.

RevServer will start the flush output process if it finds anything
that is not enclosed into a ?rev tag or if it finds the closing ?
tag.

So if you start your code with a ?rev but closes it with a ? and
then the output will also begin. This is good to know because of
includes, if you put ? in your includes, the very act of including a
file will start the output. So take those ? out of the include files.

Before anyone ask why this is so it is because PHP engine does it this
way and we decided to copy them.



 Regards,

 Gregory



-- 
http://www.andregarzia.com All We Do Is Code.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-06 Thread stephen barncard
I've also found that the 'normal' cookie listing in Safari security
preferences is difficult to work with - however *Develop:show web
inspector:storage pane*l shows cookies in a better way and refreshes easily.

For a while I thought my cookies weren't working - but it was because I was
setting the time and date to the current time - and that's the expiration
time and the entries wouldn't appear.

Here's my code for creating the correct format for the date:

blockquote

function returnCookieDate pSeconds,pGMTHours
-- returns a date compatible with cookie use:
--  Sun, 5-Sep-2010 15:25:12 GMT
--requires setOffset, below
  if pGMTHours is empty then put -0700 into pGMTHours
  if pSeconds is empty
  then
put the seconds into pSeconds
  end if
  -- add or subtract zone offset (like -0700) from local to GMT in
seconds here
  put setOffset(pSeconds,pGMTHours) into pSeconds
  convert pSeconds to dateitems
  put pSeconds into tDateItems
  convert pSeconds to  internet date  --  like Sun, 5 Sep 2010 15:25:12
-0700
  put word 1 of pSeconds into tDay
  put (word 2 of pSeconds)  -  (word 3 of pSeconds)  -  (word 4
of pSeconds) into tDate
  put word 5 of pSeconds into tTime
  replace space with - in tTime
  return tDay  tDate  tTime  GMT
end returnCookieDate

function setOffset pSecs,pGMTHours
-- 20100905
-- figures offset for time zone relating to GMT
-- example   pGMTHours = -0700
-- pSecs is the time in seconds
  if character 1 of pGMTHours is -
  then
delete character 1 of pGMTHours
put - into pSign
  else
put  into pSign
  end if
  put character 1 to 2 of pGMTHours into t6oFS -- chop trailing zeros
  put (t6oFS * 3600) into tOffsetHourSeconds
  switch pSign
case it is -
  put (psecs - tOffsetHourSeconds ) into pSecs
  break
default
  put (tOffsetHourSeconds  + pSecs ) into pSecs
  end switch
  return pSecs
end setOffset

/blockquote

On 6 September 2010 09:45, Andre Garzia an...@andregarzia.com wrote:

 On Mon, Sep 6, 2010 at 1:36 PM, Gregory Lypny
 gregory.ly...@videotron.ca wrote:
  Hi Stephen,
 
  Just to add to Andre's tip, I've found the setting and getting of cookies
 to be extremely finicky.  One thing that tripped me up for about four hours
 was the placement of ?rev in scripts.  It must appear in the very first
 line of any script involving cookies.  Leave a blank first line, and it is
 possible that everything in a script will work except for things having to
 do with cookies!
 

 Gregory,

 That is not an actual bug but a design behaviour. RevServer engine
 will output things as soon as it can, meaning that the blank line will
 be sent as is back to apache server as soon as your script starts
 executing. HTTP Headers must be sent to apache before actual output is
 sent, so if you have a blank line on top of your file, that is treated
 by the engine as hey you want to output a blank line, fine! and thus
 all the subsequent put header calls will fail since apache will pick
 that blank line and start outputing everyting as content and not as
 headers.

 RevServer will start the flush output process if it finds anything
 that is not enclosed into a ?rev tag or if it finds the closing ?
 tag.

 So if you start your code with a ?rev but closes it with a ? and
 then the output will also begin. This is good to know because of
 includes, if you put ? in your includes, the very act of including a
 file will start the output. So take those ? out of the include files.

 Before anyone ask why this is so it is because PHP engine does it this
 way and we decided to copy them.



  Regards,
 
  Gregory
 


 --
 http://www.andregarzia.com All We Do Is Code.
 ___
 use-revolution mailing list
 use-revolution@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-revolution




-- 



Stephen Barncard
San Francisco Ca. USA

more about sqb  http://www.google.com/profiles/sbarncar
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-06 Thread Gregory Lypny
Good stuff, Andre,

Thanks for the clarification.

Gregory


On Mon, Sep 6, 2010, at 1:00 PM, use-revolution-requ...@lists.runrev.com wrote:

 Gregory,
 
 That is not an actual bug but a design behaviour. RevServer engine
 will output things as soon as it can, meaning that the blank line will
 be sent as is back to apache server as soon as your script starts
 executing. HTTP Headers must be sent to apache before actual output is
 sent, so if you have a blank line on top of your file, that is treated
 by the engine as hey you want to output a blank line, fine! and thus
 all the subsequent put header calls will fail since apache will pick
 that blank line and start outputing everyting as content and not as
 headers.
 
 RevServer will start the flush output process if it finds anything
 that is not enclosed into a ?rev tag or if it finds the closing ?
 tag.
 
 So if you start your code with a ?rev but closes it with a ? and
 then the output will also begin. This is good to know because of
 includes, if you put ? in your includes, the very act of including a
 file will start the output. So take those ? out of the include files.
 
 Before anyone ask why this is so it is because PHP engine does it this
 way and we decided to copy them.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-06 Thread Andre Garzia
On Mon, Sep 6, 2010 at 2:30 PM, stephen barncard
stephenrevoluti...@barncard.com wrote:
 I've also found that the 'normal' cookie listing in Safari security
 preferences is difficult to work with - however *Develop:show web
 inspector:storage pane*l shows cookies in a better way and refreshes easily.


Stephen,

Even though Safari Developer tools gets better every release, they are
not on par with firebug. I suggest you take a look at the marvelous
combination of Firefox + Firebug

http://getfirefox.com
http://getfirebug.com

That cookie business would be really easy to debug by using Firebug
Net panel and inspecting the headers.

Cheers
andre


-- 
http://www.andregarzia.com All We Do Is Code.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-05 Thread Andre Garzia
Stephen,

I think you are using the wrong date format for the cookie. From wikipedia:

The expiration date tells the browser when to delete the cookie. The
expiration date is specified in the Wdy, DD-Mon- HH:MM:SS GMT
format. As an example, the following is a cookie sent by a Web server
(the value string has been changed):

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59
GMT; path=/; domain=.example.net

That format is similar to the internet date but it is not the internet
date. I think you will need to assemble that out of the dateitems or
something. Other way is to encode your cookie value such as it carries
expiry information on the value field itself. For example

 Set-Cookie: one=valueone#1283719646;

Then on your code you split it using # as a itemdelimiter. valueone is
your actual value, the number after the hash is the seconds, an
exact timestamp of when the cookie was set. You can use that on your
code to invalidate a cookie if needed. This puts the control of
expiration on your hands.

Andre

On Sun, Sep 5, 2010 at 5:28 PM, stephen barncard
stephenrevoluti...@barncard.com wrote:

 I am still having trouble dealing with the effective use of setting and
 clearing cookies properly using the Revolution server at On-Rev.

 put new header Set-Cookie: one=datavalue
 put new header Set-Cookie: two=datavalue2


 Yes, that sets the values that can be recovered, but to delete the cookie by
 attempting to set an early expiry date seems to fail every time.

 put new header Set-Cookie: two=datavalue2 ; expires=May 5,2010;

 put Set-Cookie:   tln  =   urlEncode(pArray[tln])  ; expires= 
 (March 24, 2012)  ;  path=/; into theCookie
 put new header theCookie


 I have been around and around to all the forums and see the same posts about
 getting put new header to work last year but nothing about actual success
 setting the expiry date.

 PHP makes it easy:

 ?php
 $value = my cookie value;

 // send a cookie that expires in 24 hours
 setcookie(TestCookie,$value, time()+3600*24);
 ?


 Tested, PHP works, just like this. Sets the date, too.

 In Rev it's as if the put new header command truncates the other parameters.


 Surely someone here has a solution to this in RevTalk.

 thanks

 sqb




 --



 Stephen Barncard
 San Francisco Ca. USA

 more about sqb  http://www.google.com/profiles/sbarncar
 ___
 use-revolution mailing list
 use-revolution@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-revolution



--
http://www.andregarzia.com All We Do Is Code.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-05 Thread stephen barncard
That was it. The date format.  Thanks very much, Andre.

sqb

On 5 September 2010 13:49, Andre Garzia an...@andregarzia.com wrote:

 Stephen,

 I think you are using the wrong date format for the cookie. From wikipedia:

 The expiration date tells the browser when to delete the cookie. The
 expiration date is specified in the Wdy, DD-Mon- HH:MM:SS GMT
 format. As an example, the following is a cookie sent by a Web server
 (the value string has been changed):

 Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59
 GMT; path=/; domain=.example.net

 That format is similar to the internet date but it is not the internet
 date. I think you will need to assemble that out of the dateitems or
 something. Other way is to encode your cookie value such as it carries
 expiry information on the value field itself. For example

  Set-Cookie: one=valueone#1283719646;

 Then on your code you split it using # as a itemdelimiter. valueone is
 your actual value, the number after the hash is the seconds, an
 exact timestamp of when the cookie was set. You can use that on your
 code to invalidate a cookie if needed. This puts the control of
 expiration on your hands.

 Andre

 On Sun, Sep 5, 2010 at 5:28 PM, stephen barncard
 stephenrevoluti...@barncard.com wrote:
 
  I am still having trouble dealing with the effective use of setting and
  clearing cookies properly using the Revolution server at On-Rev.
 
  put new header Set-Cookie: one=datavalue
  put new header Set-Cookie: two=datavalue2
 
 
  Yes, that sets the values that can be recovered, but to delete the cookie
 by
  attempting to set an early expiry date seems to fail every time.
 
  put new header Set-Cookie: two=datavalue2 ; expires=May 5,2010;
 
  put Set-Cookie:   tln  =   urlEncode(pArray[tln])  ; expires=
 
  (March 24, 2012)  ;  path=/; into theCookie
  put new header theCookie
 
 
  I have been around and around to all the forums and see the same posts
 about
  getting put new header to work last year but nothing about actual success
  setting the expiry date.
 
  PHP makes it easy:
 
  ?php
  $value = my cookie value;
 
  // send a cookie that expires in 24 hours
  setcookie(TestCookie,$value, time()+3600*24);
  ?
 
 
  Tested, PHP works, just like this. Sets the date, too.
 
  In Rev it's as if the put new header command truncates the other
 parameters.
 
 
  Surely someone here has a solution to this in RevTalk.
 
  thanks
 
  sqb
 
 
 
 
  --
 
 
 
  Stephen Barncard
  San Francisco Ca. USA
 
  more about sqb  http://www.google.com/profiles/sbarncar
  ___
  use-revolution mailing list
  use-revolution@lists.runrev.com
  Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
  http://lists.runrev.com/mailman/listinfo/use-revolution



 --
 http://www.andregarzia.com All We Do Is Code.
 ___
 use-revolution mailing list
 use-revolution@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-revolution




-- 



Stephen Barncard
San Francisco Ca. USA

more about sqb  http://www.google.com/profiles/sbarncar
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Cookies again: Expiry Date

2010-09-05 Thread Andre Garzia
On Sun, Sep 5, 2010 at 6:46 PM, stephen barncard
stephenrevoluti...@barncard.com wrote:
 That was it. The date format.  Thanks very much, Andre.

;-) been hurt by that more than once.


 sqb

 On 5 September 2010 13:49, Andre Garzia an...@andregarzia.com wrote:

 Stephen,

 I think you are using the wrong date format for the cookie. From wikipedia:

 The expiration date tells the browser when to delete the cookie. The
 expiration date is specified in the Wdy, DD-Mon- HH:MM:SS GMT
 format. As an example, the following is a cookie sent by a Web server
 (the value string has been changed):

 Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59
 GMT; path=/; domain=.example.net

 That format is similar to the internet date but it is not the internet
 date. I think you will need to assemble that out of the dateitems or
 something. Other way is to encode your cookie value such as it carries
 expiry information on the value field itself. For example

  Set-Cookie: one=valueone#1283719646;

 Then on your code you split it using # as a itemdelimiter. valueone is
 your actual value, the number after the hash is the seconds, an
 exact timestamp of when the cookie was set. You can use that on your
 code to invalidate a cookie if needed. This puts the control of
 expiration on your hands.

 Andre

 On Sun, Sep 5, 2010 at 5:28 PM, stephen barncard
 stephenrevoluti...@barncard.com wrote:
 
  I am still having trouble dealing with the effective use of setting and
  clearing cookies properly using the Revolution server at On-Rev.
 
  put new header Set-Cookie: one=datavalue
  put new header Set-Cookie: two=datavalue2
 
 
  Yes, that sets the values that can be recovered, but to delete the cookie
 by
  attempting to set an early expiry date seems to fail every time.
 
  put new header Set-Cookie: two=datavalue2 ; expires=May 5,2010;
 
  put Set-Cookie:   tln  =   urlEncode(pArray[tln])  ; expires=
 
  (March 24, 2012)  ;  path=/; into theCookie
  put new header theCookie
 
 
  I have been around and around to all the forums and see the same posts
 about
  getting put new header to work last year but nothing about actual success
  setting the expiry date.
 
  PHP makes it easy:
 
  ?php
  $value = my cookie value;
 
  // send a cookie that expires in 24 hours
  setcookie(TestCookie,$value, time()+3600*24);
  ?
 
 
  Tested, PHP works, just like this. Sets the date, too.
 
  In Rev it's as if the put new header command truncates the other
 parameters.
 
 
  Surely someone here has a solution to this in RevTalk.
 
  thanks
 
  sqb
 
 
 
 
  --
 
 
 
  Stephen Barncard
  San Francisco Ca. USA
 
  more about sqb  http://www.google.com/profiles/sbarncar
  ___
  use-revolution mailing list
  use-revolution@lists.runrev.com
  Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
  http://lists.runrev.com/mailman/listinfo/use-revolution



 --
 http://www.andregarzia.com All We Do Is Code.
 ___
 use-revolution mailing list
 use-revolution@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-revolution




 --



 Stephen Barncard
 San Francisco Ca. USA

 more about sqb  http://www.google.com/profiles/sbarncar
 ___
 use-revolution mailing list
 use-revolution@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-revolution




-- 
http://www.andregarzia.com All We Do Is Code.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution