AltME groups: search

Graham, I haven't tried to grab a cookie or anything yet, but just 
running the SO bot errors out first thing:

** Script error: lastmessage-no has no value
** Where: get ajoin case ?? do either either either -apply-
** Near: get :name

What optimizations are you looking for?

I meant system. exec didn't work. I still prefer system above passthru. 
I have integrated my first REBOL module within my website. I needed 
to add a cookie section to obey the new cookie law anyway. I even 
used a REBOL script to generate all cookie pictures to the same size 
and png format.

http://www.compkarori.co.nz:8000/Protocols/Http

 read URL [ header [ Cookie: "authtoken=anotherfoo" ]]

read/custom http://localhost.rsp?a=b&c=d[ header [ Cookie: "authtoken=anotherfoo" 
]]

Chris, the current http protocol does support custom headers with 
get like this 

read URL [ header [ Cookie: "authtoken=anotherfoo" ]]

write-net ? i need my callback on writing operations too ! just like 
read can i've this cookie ?

The ultimate cookie

Read/custom allows you to send a custom header as in a cookie header 
like this

read/custom url [post "postdata" [Cookie: "name=value"]]

we can now do this


read/custom url [get  "dummy place holder" [Cookie: "name=value"]]

and this sends the cookie header with the get request

I would prefere to have an officialy inbuild transparent cookies 
support (as I prefere not to harcode every cookie request)

If you mean that the cookie is automatically captured by the http 
protocol, and then sent with every GET/POST, then that would imply 
you need to acquire the cookie first .. whereas sometimes you know 
what the cookie is and so don't need to get it first.

If you know the cookie, you can set it inside the cookies block, 
where are stored all cokies used for automated (transparent) sending. 
But I never used it. My clasic scenario is to simulate an user with 
the web browser. That means read page with login form, submit the 
form and do whatever like normal logged user. With some pages I can 
skip the first step, but there are pages which are giving you unike 
session ids in this step and don't let you login without this first 
step.

read/custom URL compose/deep [ PUT %file.png [ Cookie: (cookie) ]]


will use the http put method to upload a binary file and sets the 
cookie

Graham, in R3's http you can use any method you want, with any headers 
you want and any content you want. Was this your question? (I do 
still need to add transparent cookie support. but that's a few minutes 
work, so it'll be there for release.)

Something I'd forgotten ... but you can set custom headers using 
the header keyword.  Not documented though.

read/custom url [ header [ cookie: "blah blah" ]]

The header keyword is not needed if you do a post though.

Oldes, thanks. I get it. You one smart cookie. Gracias.

unless the cookie is corrupting it somehow.

With Apache 2.x (normal CGI), we have: make object! [ 
	server-software: "Apache/2.0.54 (Fedora)" 
	server-name: "localhost" 
	gateway-interface: "CGI/1.1" 
	server-protocol: "HTTP/1.1" 
	server-port: "80" 
	request-method: "GET" 
	path-info: "/sample01.rhtml" 
	path-translated: "/var/www/html/sample01.rhtml" 
	script-name: "/cgi-bin/magic.cgi" 
	query-string: "" 
	remote-host: none 
	remote-addr: "127.0.0.1" 
	auth-type: none 
	remote-user: none 
	remote-ident: none 
	Content-Type: none 
	content-length: none 
	other-headers: [
		"HTTP_HOST" "localhost" 

  "HTTP_USER_AGENT" {Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) 
  Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6} 

  "HTTP_ACCEPT" {text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5} 
		"HTTP_ACCEPT_LANGUAGE" "en-us,en;q=0.5" 
		"HTTP_ACCEPT_ENCODING" "gzip,deflate" 
		"HTTP_ACCEPT_CHARSET" "ISO-8859-1,utf-8;q=0.7,*;q=0.7" 
		"HTTP_KEEP_ALIVE" "300" 
		"HTTP_CONNECTION" "keep-alive" 
		"HTTP_COOKIE" "PHPSESSID=7f84fd7766f23e1462fed550ecbbfda4"
	] 
]

is it possible to extract/change a cookie from the site a plugin 
is working in?


  I have embedded an app within an IIS served web site.  I must make 
  the reblet interact with the site's cookie, so it follows the rest 
  of the site's status when relaunched (browsing to/from the app from 
  other pages restarts the rebol app).

The approach I have is that  every session has a cookie and disk 
storage associated to the cookie. When I define a web form, the action 
method gets a continuation id as a cgi parameter, so if at that point 
you clone the browser window, you as a user have to continuation 
ids

So basically the continuations are ensured by using both the cookie 
and associated storage and the continuation id that is added to the 
links as a cgi get parameter

read/custom - can it send more than one cookie at a time ?

well, working with cookies is not all that difficult, is it? My friend 
just asked me - why rebol does not handle sessions, if any other 
language does. I told him to write it himself, but he probably does 
not know how. Isn't session just about getting a cookie, looking 
into your storage space for the cookie identifier (session identifier), 
loading the session data, using them, and storing them once again?

you just need to parse system/options/cgi/other-headers iirc. see 
temple.cgi, it shouldn't have problems with that. (but if you have 
session handling you only need one cookie in the end).

Thanks C. It is really easy isn't it?

The main differences between your approach and mine that I can see 
are:
1. you hold all data in one file; mine uses one file per session

2. you create just a cookie; mine creates a session record in which 
the CGI script can save data

Either way, the scripts demonstrate that the problem is really trivial 
-- with the one need to create unique and hard-to-guess session ids. 
 We've both put some serious code into doing that.

Hmm, im using http-tools , I login to a page which sends a cookie 
which I then have to send back everytime, however the cookie seems 
to expire after one post :/

you normally need to send the cookie each time ... that's what browsers 
do

are you getting a redirect from the second page ... that is followed 
without the cookie

maybe it is just hidden, using cookies? If you have cookie, you are 
auto-logged-on, and the session will end when you close your browser 
session?

use the cookie-enabled http protocols on rebol.org (by Cyphre IIRC)

building the wget is trivial in rebol... but you still need the http 
calls to support cookies.  though we can probably probe the headers 
for cookie returns in newer R2 versions.

It can be used in similar ways that cross-frame with cross domain 
posting used to be, and of course there are some nice third party 
cookie tricks too.

Some candidates *right now* are:
- mysql://
-postgres://
-Uniserve
-Rugby (of course ;-)
-REBgui
-cgi + cookie libs
-async http://
-async://

That last question is too short.  Would RT appreciate the potential 
of having bureaucrats trying to stick their hands in the cookie jar? 
  is more what I meant.

now the browser works like it should have in the first place


Now? getElementById has been around since 1998.. IFRAME-based JSRS 
library from 2000, Image/Cookie technique in 2000 and XMLHttpRequest 
since 2002

The tracking works even you don't have FB account. They just don't 
know your name. But they have your IP and some info from cookies. 
For example :

Referer	http://domaci.ihned.cz/c1-48204850-brezina-proc-je-lepsi-dohoda-s-ods-nez-top-09-tak-vite-no-dali-nam-vyhodnejsi-nabidku

Cookie	datr=1250632065-19088ceda338e871e9ee01df712a37723a429d0d3c22849a1d7fc; 
lu=ThbkryR2mVGidAGoXhmTtO6A; presence=DJ289860316BchADhA_22106.channelH0_5dBF289860315007WMblcPBsndPBbloMbvtMctMsbPBtA_5b_5dBfAnullBuctMsA0QBblADacA9V289859900Z400K289859900QBalAD1O1171579986ADiA0QQQQ; 
cur_max_lag=20; x-referer=http%3A%2F%2Fwww.facebook.com%2Fpermalink.php%3Fstory_fbid%3D1573166021199%26id%3D1597009707%26notif_t%3Dwall%23%2Fhome.php; 
e=n; xs=2cf8155631bb0bfe623410554919f283; sid=60; sct=1289859896; 
c_user=1597009707
The FB's cookie life is 2 years.

I think that the REBOL http scheme should have cookie support that 
you can turn on or off (don't know which the default should be).

For instance, there isn't anything in the HTTP or URL standards that 
say that the path is necessarily a hierarchy, though the (poor) cookie 
standards definitely imply it. Ignoring the cookie standards, you 
could easily look at it as a tag list. However, you would need to 
be writing the server app to do so, since the server is what decides 
what the path means.

authors of various TryREBOL systems seem to have problem with persistence. 
Wouldn't Cheyenne be of some help here? By simple cookie you could 
identify the client and have one console session for him started. 
Cookie would expire at browser's end, or with zero activity for 15 
minutes for e.g. Is there anything I am missing here?

cookie demon ?

oldes so how do you made it to get the information where can i get 
your cookie deamon ?

how can cookie harm you?

The cookie/cache idea is interesting. Need to think on that one a 
bit.

Looks good.  Does cookie handling as well.

Session are maintained by cookies, maybe you've disabled cookie support 
in your browser ?

I can see cheyenne cookie in the list of cookies for SeaMonkey ...

Doc: why not bundle mysql:// with it as well, and add a couple of 
CGI/session/cookie libs?

Nenad, there doesn't appear to be any session cookie being set after 
logging.. if that helps

It's not a short paste...
[HTTPd] ================== NEW REQUEST ==================

                                                         [HTTPd] Request Line=>GET /testapp/ HTTP/1.1

                                                                                                     [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )

                                                [HTTPd] Response=>

                                                                  HTTP/1.1 302 Moved Temporarily
Server: Cheyenne/0.9.11
Connection: close
Location: /testapp/login.rsp


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Connection closed

[HTTPd] ================== NEW REQUEST ==================        
                                        /

                                                         [HTTPd] Request Line=>GET /testapp/login.rsp HTTP/1.1

                                                                                                              [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )
[HTTPd] Response=>
                  HTTP/1.1 200 OK
Server: Cheyenne/0.9.11
Content-Length: 482
Content-Type: text/html
Connection: Keep-Alive

Set-Cookie: RSPSID=EISPOMAZTPDFKVIWJAFONZDE; expires=Sat, 02 Jun 
2007 11:54:30 GMT; path=/testapp; HttpOnly
Pragma: no-cache
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Dec 1994 16:00:00 GMT


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Phase task-done done ( mod-rsp )

[HTTPd] ================== NEW REQUEST ==================        
                                                       \

                                                         [HTTPd] Request Line=>POST /testapp/login.rsp HTTP/1.1

                                                                                                               [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8080/testapp/login.rsp
Content-Type: application/x-www-form-urlencoded
Content-Length: 23


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Posted data=>login=test&pass=letmein

                                                                                                [HTTPd] Phase access-check done ( mod-action )
 [HTTPd] Phase set-mime-type done ( mod-action )

                                                [HTTPd] Phase make-response done ( mod-rsp )
[HTTPd] Response=>
                  HTTP/1.1 301 Moved Permanently
Server: Cheyenne/0.9.11
Connection: close
Location: /testapp/

Set-Cookie: RSPSID=YDADUIONKJPHLFBWEDZDFCXN; expires=Sat, 02 Jun 
2007 11:54:37 GMT; path=/testapp; HttpOnly


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Phase task-done done ( mod-rsp )

                                                                                                                        [HTTPd] Connection closed
    [HTTPd] ================== NEW REQUEST ==================

                                                             [HTTPd] Request Line=>GET /testapp/ HTTP/1.1

                                                                                                         [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8080/testapp/login.rsp


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )

                                                [HTTPd] Response=>

                                                                  HTTP/1.1 302 Moved Temporarily
Server: Cheyenne/0.9.11
Connection: close
Location: /testapp/login.rsp


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Connection closed

                                                                                                         [HTTPd] ================== NEW REQUEST ==================

                     [HTTPd] Request Line=>GET /testapp/login.rsp HTTP/1.1

                                                                          [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8080/testapp/login.rsp


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )

                                                [HTTPd] Response=>

                                                                  HTTP/1.1 200 OK
Server: Cheyenne/0.9.11
Content-Length: 482
Content-Type: text/html
Connection: Keep-Alive

Set-Cookie: RSPSID=RTJSUKAVYBNOLCJCJBSTNUHP; expires=Sat, 02 Jun 
2007 11:54:37 GMT; path=/testapp; HttpOnly
Pragma: no-cache
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Dec 1994 16:00:00 GMT


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Phase task-done done ( mod-rsp )

tryed on port 8080 or 80? do other website write cookie in your browser 
and you can see them?

then I would say use any tool that permit you to see the header request/response, 
look closely what working websites sen in the response header for 
set-cookie change the mod-rsp to send the same apart from the RSPSID=xxx 
, eg remove path and expiration date

the cookie must be set, otherwise maybe the browser has special rules 
for order of headers (shouldn't), on wine what version of window 
and IE did u try?

Output is
>> do %raw.r
Script: "Untitled" (none)
HTTP/1.1 301 Moved Permanently
Server: Cheyenne/0.9.11
Content-Length: 1625
Content-Type: text/html
Connection: close
Location: show.rsp

Set-Cookie: RSPSID=IOERCVPFSDASSCXECGDFCTFG; expires=Sat, 02 Jun 
2007 19:54:16 GMT

<html>
<head>
    <title> Manual Sessions</title>
</head>
<body>
<img src="logo.png">
<center>
<h2>Manual session mode</h2>

SESSION is an object of value:
   content         none!     none
   timeout         none!     none
   events          none!     none
   id              none!     none
   active?         logic!    false
   init?           logic!    false
   add             function! [name [word!] value /local pos]
   remove          function! [name [word!]]
   exists?         function! [name [word!]]
   start           function! []
   reset           function! []
   end             function! []

REQUEST is an object of value:
   content         block!    length: 0
   headers         block!    length: 6
   method          word!     GET
   posted          none!     none
   client-ip       tuple!    192.168.1.102
   server-port     integer!  8080
   translated      file!     %www/dev.rsp

   parsed          object!   [headers status-line method url content 
   path targe...
   config          block!    length: 4
   web-app         none!     none
   query-string    function! [/local out]

SESSION is an object of value:
   content         block!    length: 0
   timeout         none!     none
   events          none!     none
   id              none!     none
   active?         logic!    false
   init?           logic!    false
   add             function! [name [word!] value /local pos]
   remove          function! [name [word!]]
   exists?         function! [name [word!]]
   start           function! []
   reset           function! []
   end             function! []


>>

sessions: Is it possible to add a cookie-free session handling by 
adding a session ID to the URLs?

Or is there an option for RSP to use cookie or session-id?

Btw, why would you pass session ID through URLs instead of cookies 
? Is it for users that wrongly feel more secure by not accepting 
any cookie ?

Btw, why would you pass session ID through URLs instead of cookies 
? Is it for users that wrongly feel more secure by not accepting 
any cookie ?

  - some corporate firewalls emrge cookies, effectively making all 
  session content available to all users.

I think there is missing default value for cookie expiration

Graham: cookies specification says that if domain attribut in cookie, 
is not provided, "The default value of domain is the host name of 
the server which generated the cookie response."

Seems that I found the guilty for the weird session cookie issues, 
need to dig up a little more to confirm the theory.

The session cookie problem is related to incorrect timezone calculation 
in cookies expire time. I'm making a fix for Cheyenne, but due to 
a REBOL bug on Windows (http://www.rebol.net/cgi-bin/upnews.r?view=0005), 
I can't find an easy solution for that platform...

Just a question about session data .. is that all stored in a cookie 
so that a client can alter session data, or is just the session key 
available to the client?

IIRC it is not recommended to store any actual data in cookie itself 
...

Cheyenne release v0.9.13 beta. Download at http://softinnov.org/tmp/cheyenne-r0913.zip

Changelog :


 o Session cookie management refactored. Cookies are now cached in 
 memory. 
	  Fixes all issues related to timezone.
	  

 o HTTPd request pipeline refactored. It's now more reliable, little 
 faster and

   able to handle extreme situations (stressing with FasterFox). Several 
   core parts
	  of Cheyenne have been touched, so watch out for regressions.
	  

 o Added 'forward method to RSP's Response object (now possible thanks 
 to the 
	  new pipeline engine).
	  

 o Internal modules API changed : 'deferred? property removed (not 
 needed 
	  anymore with new pipeline).
	  

 o Added 'on-status-code option in config file (see example in %httpd.cfg).
	  

 o do-sql now catches internal errors, so they can be more easily 
 located in 
	  calling context.

What i did with Framewerks is when a client logs in, I generate a 
random hash, and store it as a cookie, as well as on the DB associated 
with that user.

Set the cookie to expire in 10 hours (log in once a day)

I associate the the IP with the user a well.. if the IP is a mismatch, 
the cookie is void

Terry: I'll provide an option in the next release to add session 
cookie expiration time, but will be "at your own risks" ;-).

how about regular cookie expiry?

Regular cookie expiry, it's up to the developer to handle that (the 
RSP 'set-cookie func is still pending).

Cheyenne release v0.9.15 beta. Download at http://softinnov.org/tmp/cheyenne-r0915.zip

Changelog :

v0.9.15 - 20/06/2007


 o RConsole was not started by default in the previous release. Fixed
	

 o RSP: 'include function protection from infinite cycles changed. 
 It's

   now based on a counter (5 maximum recursive includes). It's a little 
   less

   cleaner than stack-based tracking but much more reliable (avoids 
   matching
	  paths and targets).
	  

 o HTML.r library rewritten from scratch. Now, faster and more conforming 
 to 

   standards (Full range of Latin1 entities supported). Fixes URL-encode 
   bugs.

	o BugFix for command line parsing in encapped Cheyenne on Linux.
	

 o Fixed an issue with 'decode-multipart in RSP.r. File upload should 
 work ok 
	  again.
	  

 o Added a new global function : 'rsp-log value. Outputs values in 
 console for 
	  debugging RSP scripts. Works as 'probe.
	  

 o Reloading config file now supported. Running sessions and client 
 connections

   survive to the reloading process (needs some additional testing). 
   Activating
	  config file reload is done using:
	  
	  		- (Windows) "Reload Config" menu option in systray icon.
	  		- (UNIX)     kill -s HUP pid
	  		

 o UNIX signals SIGINT,SIGQUIT,SIGTERM now catched to allow cleaner 
 exit and last

   minute actions. Triggers the new 'on-quit event for HTTPd modules.
	

 o HTTPd internal events (not phases) refactored to be cleaner. New 
 module's
	  events added:
	
			- 'on-started:	when Cheyenne starts.
			- 'on-reload:   before a config file reload happens.
			- 'on-reloaded: after a config file reload happens.
			- 'on-quit:     when Cheyenne is about to stop and quit.
			

 o RSP sessions can now be made persistent (can survive to a server 
 complete restart).

   This option is controlled by a new config keyword: 'persist. Usage 
   is :
	  	
	        persist [sessions]    ; other flags can be added at will
	        

 o BugFix in session cookie handling for web-apps using 'auth mode. 
 Now the cookie

   is sent on the 302 redirection to the login page avoiding the creation 
   of a 
	  "shadow session" that will never be used. 
	  

 o FastCGI is under heavy work so mod-fastcgi is commented in config 
 file to avoid

   fastcgi startup. If you want to play with PHP, just uncomment the 
   line.

We've got server side cookie handling, session support, db  ( mysql, 
postgresql ) and web server

A good starting point for doc links is http://www.erlang.org/doc.html
.


The pros are that it's been around for a long time, it was built 
to solve a specific type of problem, and has been proven to work 
for large commercial systems. It also has a nice community it seems. 


Just as C# and VB.net are capable languages, you really need to know 
the .NET framework to make things sing. Erlang, by itself, is very 
capable, but the OTP (Open Telecom Platform) provides a huge amount 
of value on top of it, if you're building distributed systems. It 
also has Yaws, Ejabberd, and other things already built that you 
can leverage.


On the downside, it's a very different model that takes some getting 
used to, though Maarten got up to speed for experimentation very 
quickly. If you're used to Prolog, that will help. It's also really 
only good for back end stuff, so we would still be doing front ends 
in something else, which wasn't the dealbreaker in our case. What 
turned us away was the security model. It's designed for use in an 
intranet type (read safe) environment, where access to machines on 
the cluster is controlled by secret cookie. If your cookie is compromised, 
they have absolute power over the node, and any nodes it shares that 
cookie with.  http://www.erlang.org/doc/reference_manual/distributed.html#11.7


We decided that, since we would end up building security on top of 
everything, using something like dialects for control, we were better 
off sticking with REBOL. There are a number of things out there already 
to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things 
the way we want, in a tool we know we like and are comfortable with. 
And we know its limitations, so there will be fewer surprises.

Maarten, yes you can set the secret cookie but if one system is compromised 
the whole distributed system is. how is that different in other architectures 
?

I think Cheyenne's webapps are protected by cookie authentication

I see req/in/headers/Cookie gets the cookie, but setting it how?

Can set with javascript 
<script>

document.cookie ='cheyenne=testcookie; expires=Thu, 15 Oct 2008 20:47:11 
UTC; path=/'
</script>

the biggest blockage in developing learning was just now when I was 
making login function and it stopped setting cookie, it took me at 
least half an hour looking at the code and then I discovered I disabled 
cookies by accident in FF webdev toolbar :)

New Cheyenne test release 0.9.19 available. Please report any bug 
or regresson here.

Changelog (diff from previous one) :


  o RSP: fixed a security issue allowing access to /webapp/private/ 
  sub-folders content.
	 

  o RSP/CGI: fix for HTTP 'Date header not being returned in some cases.(Will)
	 

  o RSP Sessions: fixed an issue with init flag when saving sessions 
  on disk.(Will)
	 
	 o RSP: now you can declare folders as valid login URL.(Will)
	 
	 	Ex: auth "/admin/login/"
	 	

  o RSP: a new session word 'from has been added. It's set to the referring 
  URL on login.

    After login, you can now redirect to the referring page (in case 
    of session timeouts
	   for example).(Will)
	   

  o RSP: a webapp can now be called without the ending slash.(Will)
	 

  o RSP: the root "/" webapp can now be declared (needs testing).(Will)
	 	 

  o RSP: new 'SID-domain config keyword added allowing to share sessions 
  between
	   sub-domains.(Will)
	 

  o RSP: now session ID can be passed as URL or POST data in addition 
  to cookie.(Will)
	 

  o New 'charset config keyword added. It allows to define specific 
  charset sent through
	   HTTP headers for 'text/htlm resources.(Will)
	   

  o RSP: Added a new function no-log in Response object. Use it to 
  avoid writing
	   log info to disk for the current request.(Will)
	   
	   		Ex: response/no-log


  o New 'mod-expire module for HTTPd. Allow configuring 'Expires HTTP 
  header. 
	   See %Cheyenne/mods/mod-expire.r for more info.(Will)

Before setting-up the reverse-proxy config so that I can use cheyenne 
with all RSP features I have some questions:


1. Session handling: I understand that sessions can now be used via 
cookie, URL-parameter or POST data. How do I select which method 
to use? Can I start with Cookies and if this fails (can this be detected?) 
fall back to the other methods?

1. When first accessed, a RSP web application will send you a session 
ID by cookie. You can send it back by cookie or included in GET or 
POST data. If you want your session ID passed inside the HTML page 
in all URLs, you have to add it in your RSP source using some code 
like : rejoin ["RSPSID=" session/id].

1. "You can send it back by cookie or included in GET or POST data." 
Well, my understanding is that the YOU here refers to the delivered 
page. So, the page needs to be prepared a priori to delivering with 
either the session-id etc.

But if I do this, I won't need a cookie at all.


So, I first need to check if cookies work? Is there a simple test 
function in RSP like: COOKIES-AVAILABLE?

3. Blocks: That's the way I want to go. Using the session ID to store 
shopping-carts. And than a clean-out run after several days or so.


The problem with the session-ID not being a cookie is, that the session 
is lost if the user closes the browser and later returns. Right?

1. Good point. You need to use the session/active? to test if a session 
has been automatically created, if not, that means no cookie support 
(require to serve a RSP page first, then check on the next call to 
a RSP page, an HTTP redirection might help you do so). Then, you 
can use session/start to manually start the session and send back 
the SID.

3. Ok. So, if the browser window is closed, the session cookie will 
be deleted? Or will the session survive a window close if the client 
accepts cookies?

Yes, that's my understanding as well. That's why I want to cross-check 
what kind the session-ID cookie in Cheyenne is.

The cookie setter can specify a deletion date, in which case the 
cookie will be removed on that date. If the cookie setter does not 
specify a date, the cookie is removed once the user quits his or 
her browser.

just wanted to drop by and say that I published alpha of my first 
mini cheyenne webapp and it is the most responsive app I ever made 
.. it is noted also when not on local comp and someone of 2 peps 
that tried it already wondered how come it loads so fast ...  this 
is minimal app so it looks more reasonable but I know a slightly 
bigger app that I am making behaves just as fast for now..  have 
to run.. will read this cookie discussion other time

From faq:

A webapp is a directory in the webspace which is protected by an 
authentication cookie. It is specified inside the httpd.cfg, where 
there is a sample "testapp".

And how is the authentification cookie made, sent, ...?

A session is a block! of name / value pairs that is kept in Cheyenne's 
main process and exchanged with worker process. A synchronization 
system is there to avoid concurrency issues. The SID sent by cookie 
to the client is just a lookup key. When sent back to the server, 
this key allows to identify the right session object to pass to the 
RSP script in a worker process.


You are only limited by memory, but remember that the session object 
is MOLDed / LOADed and exchanged by TCP twice for a RSP request. 
So, in order to keep your RSP pages fast enough and scale well with 
a growing number of active users, keep the session block! as small 
as possible.

If you want to access a web app from Rebol

page: open login-url ; a rsp session is sent to you
page/locals/headers/set-cookie contains the cookie

page: read/custom login-url compose/deep [ POST (auth) [ cookie: 
(cookie)]] ; where auth is your authentication string eg. "login=user&pass=mypassword"
you are now authenticated
and if you now what to access a page in the web app

page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]]


where you need to use my modified http protocol that allows you to 
send cookies with read/custom

Web-Apps Login: Is basic authentication supported? I have a situation 
where form-and-cookie authentication is awkward.

Same as session cookie : RSPSID

yes, dialect based solution would be very interesting ... I was thinking 
about dialects a little too (not concrete yet) ... currently my testing 
engine is made so that it uses a proxy and it records your what you 
do via browser and then it can repeat the same and comparte the output 
(it already figures out that it needs to set different cookie and 
some basic stuff to login for example , and I have idea to make it 
scriptable for other dynamic data but I haven't come that far yet 
) . It also doesn't do any smart comparisson of the outputs, but 
more of a report for human to view for now

actually the resource url is already saved when a session timeout, 
this is the code in mod-rsp.r:
req/out/code: 302
					sessions/set-cookie sess req
					h-store req/out/headers 'Location url
					h-store req/out/headers 'Last-Modified none
					repend sess/vars ['from req/in/url]
					throw true 	; redirects to login page

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Wed, 19 Aug 2009 07:41:04 GMT
Expires: Wed, 19 Aug 2009 07:41:04 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
Server: GFE/2.0
Via: 1.1 bc3
Content-Length: 0
Connection: Keep-Alive
Set-Cookie: cookies here ... 

Set-Cookie: user=; Expires=Tue, 18-Aug-2009 07:41:04 GMT; Path=/; 
HttpOnly

Set-Cookie: login=; Expires=Tue, 18-Aug-2009 07:41:04 GMT; Path=/; 
HttpOnly

You don't have anymore, it looks like it's not related to old session 
cookie afterall. At least one ticket is opened in Chrome's tracker, 
but not confirmed by developers: http://code.google.com/p/chromium/issues/detail?id=1267

Hi Doc, one small thing... Chrome browser does not remember the login 
password cookie.