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: 36 end: 135]
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: !AltME ... Discussion about AltME [web-public] | ||
Anton: 17-Nov-2010 | Bug: The old inconsistent bug of failing to copy the text of a message by simple right-click prevented me from copying Oldes' message with the long referrer link and cookie data in it, so I selected the message text first before right-click. That worked, but then all messages in the display began disappearing (looks like a shared para scroll bug). Even switching groups. Right now I'm looking at !AltME with several blank messages - only the dates appear normally. | |
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: 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: 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: !Cheyenne ... Discussions about the Cheyenne Web Server [web-public] | ||
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 | |
Will: 19-Aug-2009 | why do u have Content-Length: 0 ? this is not valid Set-Cookie: cookies here ... | |
Graham: 19-Aug-2009 | this is the request GET /md/creategoogledoc.rsp?gdoc=simple-letter.rtf&patientid=2832&encounter=none HTTP/1.1 Host: gchiu.no-ip.biz:8000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 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://gchiu.no-ip.biz:8000/md/Listgoogledocs.rsp Cookie: RSPSID=QZPTPCZIWWMMYBKWHWRQETGM | |
Will: 19-Aug-2009 | ok here is the answer from Cheyenne: HTTP/1.1 301 Moved Permanently Server: Cheyenne/0.9.20 Date: Thu, 20 Aug 2009 09:43:23 GMT Connection: close Location: http://docs.google.com/Doc?docid=0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu&hl=en Set-Cookie: RSPSID=OTWARJZIFLZYABVJOACFFTZY; path=/md; HttpOnly | |
Will: 19-Aug-2009 | answer from the redirection: HTTP/1.1 302 Moved Temporarily Content-Type: text/html; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Date: Wed, 19 Aug 2009 21:43:58 GMT Set-Cookie: WRITELY_UID=001dfpwvx2b|928b9de9e7bf56448b665282fc69988b; Path=/; HttpOnly Set-Cookie: GDS_PREF=hl=en;Expires=Sat, 17-Aug-2019 21:43:58 GMT;HttpOnly Set-Cookie: SID=DQAAAHcAAAB0kldc4zZSC_0FoiL6efkWE11k9SQkAIn-N3WfAzIOVe1cM-remnLUtV3Z4M-BFRf5eknz7hr_U3YzW94nECo0-aDnpxrLGiBglWGN4VkfLr5Hh7t2XNyRCA3VWd005SfCmZ9D8-1MUltjRI8X56VLde5Wy8HD92gh-8YkJBJxQA;Domain=.google.com;Path=/;Expires=Sat, 17-Aug-2019 21:43:58 GMT Location: https://www.google.com/accounts/ServiceLogin?service=writely&passive=true&nui=1&continue=http%3A%2F%2Fdocs.google.com%2FDoc%3Fdocid%3D0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu%26amp%3Bhl%3Den&followup=http%3A%2F%2Fdocs.google.com%2FDoc%3Fdocid%3D0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu%26amp%3Bhl%3Den<mpl=homepage&rm=false Content-Encoding: gzip X-Content-Type-Options: nosniff Content-Length: 325 Server: GFE/2.0 | |
Will: 19-Aug-2009 | more redirection: HTTP/1.1 302 Moved Temporarily Set-Cookie: WRITELY_SID=DQAAAHoAAADh80lBIw7e5Hg06TLEBgCY33XQGJ1aUH5OrCF_ir1xLwffKNaCqNdUL6qYfvgjNppDBI4lTNBSTjJWMG_Ze0_qJnveBCAtihBDFwBlOb-H7RlkfgJwM7pBbyKV7bm4M3mqUivD1emtpxgl32vG8CEP1poQ2479HQXrlobsp7Egzw;Domain=docs.google.com;Path=/;Expires=Thu, 03-Sep-2009 21:43:59 GMT Location: http://docs.google.com/Doc?docid=0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu&%3Bhl=en&pli=1 Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip Date: Wed, 19 Aug 2009 21:43:59 GMT Expires: Wed, 19 Aug 2009 21:43:59 GMT Cache-Control: private, max-age=0 X-Content-Type-Options: nosniff Content-Length: 232 Server: GFE/2.0 | |
Will: 19-Aug-2009 | and the the target page: HTTP/1.1 200 OK Set-Cookie: WRITELY_SID=DQAAAHoAAADh80lBIw7e5Hg06TLEBgCY33XQGJ1aUH5OrCF_ir1xLwffKNaCqNdUL6qYfvgjNppDBI4lTNBSTjJWMG_Ze0_qJnveBCAtihBDFwBlOb-H7RlkfgJwM7pBbyKV7bm4M3mqUivD1emtpxgl32vG8CEP1poQ2479HQXrlobsp7Egzw;Domain=docs.google.com;Path=/;Expires=Thu, 03-Sep-2009 21:43:59 GMT Set-Cookie: GDS_PREF=hl=en;Expires=Sat, 17-Aug-2019 21:43:59 GMT;HttpOnly Set-Cookie: user=; Expires=Tue, 18-Aug-2009 21:43:59 GMT; Path=/; HttpOnly Set-Cookie: login=; Expires=Tue, 18-Aug-2009 21:43:59 GMT; Path=/; HttpOnly Content-Type: text/html; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Date: Wed, 19 Aug 2009 21:43:59 GMT Content-Encoding: gzip Transfer-Encoding: chunked X-Content-Type-Options: nosniff Server: GFE/2.0 | |
Graham: 19-Aug-2009 | Anyone see why this doesn't work grab-cookie: func [ login-url [url!] username password /target web-app-url [url!] /local page auth cookie err ][ if error? set/any 'err try [ page: open login-url cookie: page/locals/headers/set-cookie close page auth: rejoin [ "login=" username "&pass=" password ] page: read/custom login-url compose/deep [ POST (auth) [ cookie: (cookie)]] either target [ page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]] return page ][ return cookie ] ][ mold disarm err ] ] I can see it sending the cookie after authentication to get a page in a web-app, but I get redirected to the login age | |
Dockimbel: 19-Aug-2009 | Grab-cookie: does your 'username or 'password values contain any special character that would need to be URL-encoded? | |
Janko: 24-Nov-2009 | set-cookie docs don't exist and it says n/a .. does this mean the word is not there any more or something else? Do I have to manually set http response headers to set cookies? | |
Dockimbel: 24-Nov-2009 | Set-cookie is on the todo list but hasn't been implemented yet. So, for now, you have to set http header manually. | |
Dockimbel: 24-Nov-2009 | request/headers/cookie | |
Terry: 22-Dec-2009 | Some advantages to the ws:// spec - Seamlessly traverse firewalls and routers - Allow duly authorized cross-domain communication - Integrate well with cookie-based authentication - Integrate with existing HTTP load balancers - Be compatible with binary data | |
Dockimbel: 31-Dec-2009 | That comes from the way web socket's connection are initiated, it starts like a simple HTTP GET request and the server is supposed to validate that request, check access authorization if required, etc... So, to avoid duplicating work, I choose to re-use RSP framework as much as possible. The initial ws:// URL must point to a valid RSP script so that the server can check, for example, RSP session cookie for access rights. | |
Terry: 6-Jan-2010 | Updated version of Doc's chat example.. - Enter key support for login and posting chats - Cookie mgmt for user name - various "tweaks" to the JQuery chat2.html: http://pastebin.com/m66a38d50 | |
Terry: 7-Jan-2010 | That chat.html I made was a quick hack of yours. Need to build proper cookie mgmt functions.. deal with sessions etc. | |
Graham: 13-Feb-2010 | if you want to let users login, then you need to track a session cookie | |
GrahamC: 2-Dec-2010 | This is what I am sending HTTP/1.1 200 OK Server: Cheyenne/0.9.20 Date: Thu, 02 Dec 2010 15:33:25 GMT Content-Length: 475 Content-Type: application/vnd.adobe.xfdf Connection: Keep-Alive Content-Encoding: deflate Set-Cookie: RSPSID=XESYTVZSEFSXPQHCTITGRDQG; path=/md; HttpOnly Cache-Control: private, max-age=0 Expires: -1 Firefox opens up the PDF referenced in the xfdf file that is downloaded. Chrome just downloads and saves the content. So maybe it's just Chrome's PDF "plugin" that doesn't understand what to do ... | |
james_nak: 3-Mar-2011 | Doc, I'm thinking this version fixed my cookie issue with Curecode . We'll see. So far it looks great. Merci. | |
onetom: 4-May-2011 | ehh... sessions are not lazily created either... and i couldn't even set-header 'set-cookie none session/end because it sends down 2 cookies then... | |
onetom: 8-May-2011 | Cookie {RSPSID=YVCBKGUZKHKSJGXVCBSTYDIK; RSPSID=YARKPZJMKJUNWDZRFOLUKJTE} login "test" pass "letmein" Session ID "YARKPZJMKJUNWDZRFOLUKJTE" | |
onetom: 8-May-2011 | yes, it's not sending the cookie as i would expect on the 2nd run | |
onetom: 8-May-2011 | $ cat jar # Netscape HTTP Cookie File # http://curl.haxx.se/rfc/cookie_spec.html # This file was generated by libcurl! Edit at your own risk. #HttpOnly_guan-huat FALSE / FALSE 0 RSPSID MTXVGMVOMYMVGDZKFURKPQKK | |
Dockimbel: 8-May-2011 | You should stick with REBOL HTTP client, using this patch to add transparent cookie support: http://www.rebol.org/view-script.r?script=my-http.r | |
onetom: 8-May-2011 | u know if rebol would come w a nicer header dump, cookie, https and url encode/decode support by default, i would advocate it as a curl replacement probably... :/ maybe an extension script would be enough, which anyone can remember, like http://json.org/json.r | |
onetom: 8-May-2011 | hmm.. cookies are accumlating again... Cookie: RSPSID=GWKAQXFYMANHFHNXLXXKVVWL; RSPSID=VDWMLITKUVGDAFQBHJHHCQDH but the app still works. am i confusing it somehow, by restarting cheyenne... but im closing the tab and reopening it too... | |
onetom: 14-May-2011 | because it always gets sent w all the http requests then, if it's stored in a cookie. so if u have images in the same domain(/folder) for example, then data is sent for those too | |
Maxim: 15-May-2011 | yeah, using cookies for storage isn't a good idea... also since many people are using cookie controlers now. | |
Group: !REBOL2 Releases ... Discuss 2.x releases [web-public] | ||
Graham: 25-Apr-2010 | It might be a good idea to patch in Cyphre's cookie handling support as well http://www.rebol.org/view-script.r?script=my-http.r | |
Group: !CureCode ... web-based bugtracking tool [web-public] | ||
Carl: 28-Dec-2009 | Hi Doc, one small thing... Chrome browser does not remember the login password cookie. | |
james_nak: 11-Oct-2010 | OK, this morning, I went into FF's Cookie browser and searched for cookies from my domain where curecode is. There were none. I went to view my curecode page and it was not going to work. I know this because the project select shows "none." I then went back to the cookies section and there was one for the domain. I deleted that, refreshed the curecode page and it worked. Now, one thing about my usual usage of curecode and that is during any given day, I will end up logging in several times after my sessions expire. | |
james_nak: 11-Oct-2010 | 0.9.11 beta. Sometimes I am redirected to the login screen but the selection is none and from there it will go to the rsp error. Thanks. Knowing that I can remove that cookie is pretty easy. | |
james_nak: 22-Jun-2011 | Doc, I still have issues with the cookies created from Curecode. Essentially, when I leave the browser open and the session expires, the next time I try to use curecode, it loads up the error page. I just manually delete the cookie and I'm good and I have extended the timeout as well which helps. I was wondering in the httpd.cfg file if there is any value for curecode's timeout that will make it endless (perhaps "none" ? ). Thanks. It is a very usefule app. | |
james_nak: 22-Jun-2011 | I use FF 5.0 (just upgraded this morning though. Previously it was 4.0.1). As far as cookie altering tools, not that I know of, though I was wondering if AVG could be doing something. Anyway, I just cost you a few lost Red minutes. I'll wait until it happens again. Thanks. | |
Group: Core ... Discuss core issues [web-public] | ||
james_nak: 12-Mar-2011 | I think this is a Graham question. I've been trying to communicate with this video encoder. It uses .xml and .cgi files to talk to it: tmp: http-tools http://192.168.1.62/user/GetTTLStatus.xml[] and this works fine. The problem is with he .cgi files. They aren't POST files but they only return a: http-tools http://192.168.1.62/user/StorageMediaFiles.cgi[] probe a make object! [ HTTP-Response: "<?xml version='1.0' encoding='ISO-8859-1' ?>" Date: none Server: none Last-Modified: none Accept-Ranges: none Content-Encoding: none Content-Type: none Content-Length: none Location: none Expires: none Referer: none Connection: none Set-Cookie: none ] When you place the url in a browser it works as expected. Any ideas on how to get this to work? | |
james_nak: 12-Mar-2011 | And you're right, there is probably something else going on. I am at least getting part of the message. A successful .xml call looks like this: a: http-tools http://192.168.1.62/user/StorageEventMode.xml[] probe a make object! [ HTTP-Response: "HTTP/1.1 200 OK" Date: none Server: "Mango DSP - HTTP Server (v2.34)" Last-Modified: none Accept-Ranges: none Content-Encoding: none Content-Type: "text/xml" Content-Length: "270" Location: none Expires: none Referer: none Connection: none Set-Cookie: none Cache-Control: "no-store" content: {<?xml version="1.0" encoding="ISO-8859-1" ?> <?xml-stylesheet type="text/xsl" href="StorageEventMode.xsl"?> <StorageEventMode> ^-<RecOnNetworkFailure id="RecOnNetworkFailure" checked="true"/> ^-<PreEventBufferTime id="PreEventBufferTime" value="20"/> </StorageEventMode> } ] |
1 / 136 | [1] | 2 |