AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 4 |
r3wp | 132 |
total: | 136 |
results window for this page: [start: 1 end: 100]
world-name: r4wp
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
Gregg: 1-Mar-2013 | 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? | |
Group: Rebol School ... REBOL School [web-public] | ||
Arnold: 13-Jul-2012 | 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. | |
GrahamC: 11-Dec-2012 | http://www.compkarori.co.nz:8000/Protocols/Http read URL [ header [ Cookie: "authtoken=anotherfoo" ]] | |
Group: Web ... Anything related to the WWW [web-public] | ||
GrahamC: 28-Sep-2012 | read/custom http://localhost.rsp?a=b&c=d[ header [ Cookie: "authtoken=anotherfoo" ]] |
world-name: r3wp
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
Graham: 23-Aug-2010 | Chris, the current http protocol does support custom headers with get like this read URL [ header [ Cookie: "authtoken=anotherfoo" ]] | |
Group: RAMBO ... The REBOL bug and enhancement database [web-public] | ||
Benjamin: 16-Aug-2005 | write-net ? i need my callback on writing operations too ! just like read can i've this cookie ? | |
Group: Core ... Discuss core issues [web-public] | ||
Volker: 26-Jan-2007 | The ultimate cookie | |
Graham: 19-Sep-2008 | Read/custom allows you to send a custom header as in a cookie header like this read/custom url [post "postdata" [Cookie: "name=value"]] | |
Graham: 19-Sep-2008 | we can now do this read/custom url [get "dummy place holder" [Cookie: "name=value"]] | |
Graham: 19-Sep-2008 | and this sends the cookie header with the get request | |
Oldes: 20-Sep-2008 | I would prefere to have an officialy inbuild transparent cookies support (as I prefere not to harcode every cookie request) | |
Graham: 20-Sep-2008 | 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. | |
Oldes: 20-Sep-2008 | 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. | |
Graham: 22-Sep-2008 | 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 | |
Gabriele: 23-Sep-2008 | 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.) | |
Graham: 11-Jun-2010 | 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. | |
Group: Parse ... Discussion of PARSE dialect [web-public] | ||
james_nak: 10-Oct-2006 | Oldes, thanks. I get it. You one smart cookie. Gracias. | |
Graham: 29-Dec-2006 | unless the cookie is corrupting it somehow. | |
Group: CGI ... web server issues [web-public] | ||
François: 25-Jul-2005 | 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" ] ] | |
Maxim: 26-Feb-2007 | 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). | |
Group: Web ... Everything web development related [web-public] | ||
Joe: 10-Feb-2006 | 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 | |
Joe: 10-Feb-2006 | 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 | |
Anton: 15-Feb-2006 | read/custom - can it send more than one cookie at a time ? | |
Pekr: 6-Nov-2006 | 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? | |
Gabriele: 7-Nov-2006 | 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). | |
Sunanda: 18-Dec-2006 | 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. | |
CharlesS: 24-Jan-2007 | 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 :/ | |
Graham: 24-Jan-2007 | you normally need to send the cookie each time ... that's what browsers do | |
Tomc: 24-Jan-2007 | are you getting a redirect from the second page ... that is followed without the cookie | |
Pekr: 15-Apr-2008 | 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? | |
Maxim: 23-Sep-2010 | use the cookie-enabled http protocols on rebol.org (by Cyphre IIRC) | |
Maxim: 23-Sep-2010 | 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. | |
Group: DevCon2005 ... DevCon 2005 [web-public] | ||
Allen: 4-Oct-2005 | 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. | |
Group: PowerPack ... discussions about RP [web-public] | ||
Maarten: 23-May-2005 | Some candidates *right now* are: - mysql:// -postgres:// -Uniserve -Rugby (of course ;-) -REBgui -cgi + cookie libs -async http:// -async:// | |
Group: Rebol School ... Rebol School [web-public] | ||
btiffin: 31-Jan-2008 | 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. | |
Group: AJAX ... Web Development Using AJAX [web-public] | ||
Terry: 4-Mar-2006 | 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 | |
Group: Tech News ... Interesting technology [web-public] | ||
Oldes: 17-Nov-2010 | 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. | |
Group: !REBOL3-OLD1 ... [web-public] | ||
BrianH: 11-Apr-2009 | 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). | |
BrianH: 17-Jul-2009 | 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. | |
Pekr: 2-Oct-2009 | 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? | |
shadwolf: 2-Dec-2009 | cookie demon ? | |
shadwolf: 2-Dec-2009 | oldes so how do you made it to get the information where can i get your cookie deamon ? | |
Group: Plugin-2 ... Browser Plugins [web-public] | ||
Pekr: 15-Jun-2006 | how can cookie harm you? | |
JoshM: 16-Jun-2006 | The cookie/cache idea is interesting. Need to think on that one a bit. | |
Graham: 4-Jul-2006 | Looks good. Does cookie handling as well. | |
Group: !Cheyenne ... Discussions about the Cheyenne Web Server [web-public] | ||
Dockimbel: 9-Oct-2006 | Session are maintained by cookies, maybe you've disabled cookie support in your browser ? | |
Pekr: 9-Oct-2006 | I can see cheyenne cookie in the list of cookies for SeaMonkey ... | |
Maarten: 11-Oct-2006 | Doc: why not bundle mysql:// with it as well, and add a couple of CGI/session/cookie libs? | |
Terry: 30-May-2007 | Nenad, there doesn't appear to be any session cookie being set after logging.. if that helps | |
btiffin: 2-Jun-2007 | 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 ) | |
Will: 2-Jun-2007 | tryed on port 8080 or 80? do other website write cookie in your browser and you can see them? | |
Will: 2-Jun-2007 | 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 | |
Will: 2-Jun-2007 | 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? | |
btiffin: 2-Jun-2007 | 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! [] >> | |
Robert: 3-Jun-2007 | sessions: Is it possible to add a cookie-free session handling by adding a session ID to the URLs? | |
Robert: 3-Jun-2007 | Or is there an option for RSP to use cookie or session-id? | |
Dockimbel: 3-Jun-2007 | 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 ? | |
Maarten: 3-Jun-2007 | 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. | |
Oldes: 3-Jun-2007 | I think there is missing default value for cookie expiration | |
Dockimbel: 3-Jun-2007 | 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." | |
Dockimbel: 3-Jun-2007 | Seems that I found the guilty for the weird session cookie issues, need to dig up a little more to confirm the theory. | |
Dockimbel: 3-Jun-2007 | 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... | |
Graham: 5-Jun-2007 | 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? | |
Pekr: 5-Jun-2007 | IIRC it is not recommended to store any actual data in cookie itself ... | |
Dockimbel: 6-Jun-2007 | 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. | |
Terry: 10-Jun-2007 | 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. | |
Terry: 10-Jun-2007 | Set the cookie to expire in 10 hours (log in once a day) | |
Terry: 10-Jun-2007 | I associate the the IP with the user a well.. if the IP is a mismatch, the cookie is void | |
Dockimbel: 10-Jun-2007 | Terry: I'll provide an option in the next release to add session cookie expiration time, but will be "at your own risks" ;-). | |
Terry: 10-Jun-2007 | how about regular cookie expiry? | |
Dockimbel: 10-Jun-2007 | Regular cookie expiry, it's up to the developer to handle that (the RSP 'set-cookie func is still pending). | |
Dockimbel: 20-Jun-2007 | 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. | |
Graham: 22-Oct-2007 | We've got server side cookie handling, session support, db ( mysql, postgresql ) and web server | |
Gregg: 23-May-2008 | 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. | |
Joe: 29-May-2008 | 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 ? | |
Graham: 9-Oct-2008 | I think Cheyenne's webapps are protected by cookie authentication | |
Terry: 12-Oct-2008 | I see req/in/headers/Cookie gets the cookie, but setting it how? | |
Terry: 12-Oct-2008 | Can set with javascript <script> document.cookie ='cheyenne=testcookie; expires=Thu, 15 Oct 2008 20:47:11 UTC; path=/' </script> | |
Janko: 11-Jan-2009 | 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 :) | |
Dockimbel: 3-Feb-2009 | 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) | |
Robert: 12-Feb-2009 | 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? | |
Dockimbel: 12-Feb-2009 | 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]. | |
Robert: 12-Feb-2009 | 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? | |
Robert: 12-Feb-2009 | 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? | |
Dockimbel: 12-Feb-2009 | 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. | |
Robert: 12-Feb-2009 | 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? | |
Robert: 12-Feb-2009 | Yes, that's my understanding as well. That's why I want to cross-check what kind the session-ID cookie in Cheyenne is. | |
Robert: 12-Feb-2009 | 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. | |
Janko: 12-Feb-2009 | 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 | |
Oldes: 16-Feb-2009 | 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". | |
Robert: 16-Feb-2009 | And how is the authentification cookie made, sent, ...? | |
Dockimbel: 26-Feb-2009 | 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. | |
Graham: 28-Mar-2009 | 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 | |
BrianH: 30-Apr-2009 | Web-Apps Login: Is basic authentication supported? I have a situation where form-and-cookie authentication is awkward. | |
Dockimbel: 30-Apr-2009 | Same as session cookie : RSPSID | |
Janko: 16-May-2009 | 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 | |
Will: 17-Aug-2009 | 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 | |
Graham: 19-Aug-2009 | 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 | |
Group: !CureCode ... web-based bugtracking tool [web-public] | ||
Dockimbel: 9-Feb-2009 | 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 | |
Carl: 28-Dec-2009 | Hi Doc, one small thing... Chrome browser does not remember the login password cookie. |
1 / 136 | [1] | 2 |