Using 'acgiss.r to preserve CGI 'sessions'

[jfdutcher]

The code below uses Sunanda's acgiss.r to maintain session continuity.
What I'm trying to unravel is why the "session was new" output is produced every time the script (blog.r) is accessed. Access is from 'localhost' to my Abyss Webserver
running on the local machine. It's as though the save-session doesn't happen. but there is an entry in the acgiss-work-folder for each connection.

do %acgiss.r

SESSION-RECORD: acgiss/get-session-record

either SESSION-RECORD/session-status = "new" [
   print "session was new"
        either cgi-obj/query-string = "nagle222" [
      append SESSION-RECORD/user-data ["nagle222"]
         acgiss/save-session SESSION-RECORD
         admin-ip: copy [127.0.0.1]
         remote-ip: copy [127.0.0.1]
   ][  append SESSION-RECORD/user-data [" "]
        acgiss/save-session SESSION-RECORD
        admin-ip: copy[129.1.1.1]
        remote-ip: copy[130.3.3.3]
   ]         
][     print "session was old"
   either SESSION-RECORD/user-data = "nagle222" [      
      admin-ip: copy [127.0.0.1]
      remote-ip: copy [127.0.0.1]
   ][   admin-ip: copy [129.1.1.1]
      remote-ip: copy [130.3.3.3]       
   ]
]   

[Sunanda]

Just a guess -- if acgiss.r is creating a new session record on each invocation, then it may be failing to retrieve the cookie:

Do you have cookies enabled with the browser you are using?

Does this find your cookie:
select system/options/cgi/other-headers "HTTP_COOKIE"

[jfdutcher]

Sununda:

I cleared the cookies folder for my Firefox browser (yes, it does write them) and started fresh. Again the acgissi.r script writes the new session data to the acgissi-work-folder for each hit....but nothing is written to the Firefox cookies folder.
I tried visiting Yahoo.com to retrieve mail....and immediately (4) cookies were written to the Firefox cookies folder.

Is it possible that Firefox only responds to 'remote' web sites...not 'localhost' for cookie writing .......   H-m-m-m  I don't  know.

John D.

[jfdutcher]

To follow up on your suggestion....I placed this line into the blog.r script:

[jfdutcher]

Sorry....wrong key I guess....
I placed this line into the blog.r script as shown below:

           print [select system/options/cgi/other-headers "HTTP_COOKIE"]

It returns 'none'......

do %acgiss.r
print [select system/options/cgi/other-headers "HTTP_COOKIE"]

SESSION-RECORD: acgiss/get-session-record

[Sunanda]

Firefox is happy to handle cookies for me locally, so I don't think that is the issue.

Two possibilities:

1. multiple cookies

It is possible that you have more than  one local cookie in the Firefox cookies cache.

acgiss.r only handles the simple Type 1 cookie, so sending it multiple cookies means it can't find any.

This seems unlikely unless you are testing different applications locally; and. anyway, you cleared the cache.

2. misplaced save-session

The save-session is what sends the cookie to the output stream (and thus gets it to the web browse).

HTTP rules say that must happen before you print any HTML. If the cookie is written later, it is seen as part of your HTML data.

This code works for me under Firefox:

Code:

#!shebang here
rebol[]
print "Content-type: text/html^/"
SESSION-RECORD: acgiss/get-session-record ;; retrieve session data
acgiss/save-session SESSION-RECORD       ;; save the data

print <h1>
print "test acgiss.r"
print </h1>


either SESSION-RECORD/session-status = "new" [
    print ["<h2> New </h2>"]
    ][
    print ["<h2> OLD </h2>"]
     ]

print <pre>
print mold session-record
print </pre>

quit

Note the save-session happens before the first print of HTML content.

If that causes some awkwardness in your application, you can do multiple save-sessions: only the first in a session will write the cookie.

[jfdutcher]

Thanks much.......I'm at work right now and can't try the suggestion immediately...but have little doubt that this is the issue. I'm quite sure I have output'ed  html prior to issuing the SAVE-SESSION.

[Sunanda]

Assuming it is the second issue.....

My logic isn't quite right in the example: doing the save-session will set the session-status to "old" -- f you do a get-session-record and immediately follow it by a save-session (like what I just did) you will only ever see a session status of old.

There are two approaches to solving that:

1. save the status

As it says, add a line of code after the get-session-record to copy the status value.

2 only do one print at the very end
This is the way all my CGI applications work: the very last line of code is always:
  send-output

Where send-output is a function that does various things -- writes the HTML headers, saves the session status, writes the page contents.

Of course, that assumes you've built up the page contents in a variable rather than printed it at various points in the application.

This approach does allow arbitrary bits of code to write HTTP headers -- example, perhaps you are halfway through a CGI script when logic (or error conditions) require you to bail out with a HTTP redirect or some sort of HTTP error status. If you know your application has not written any content, you can do that with a print and a quit. Otherwise it is impossible to rollback the prints already issued.