From farukscan at gmail.com Thu Mar 20 21:08:34 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Thu, 20 Mar 2014 23:08:34 +0200 Subject: yet another session problem Message-ID: no offense. I need help on hunchentoot session topic. whether I am doing a very simple mistake, or there is an issue. I do not need do not send your code and beg for help to solicit help as somebody has told days before this is very basically should work as I am expecting. It is very simple. to ensure installs are done: (ql:quickload '(:hunchentoot)) (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 5050)) (defun f () (let ((username (hunchentoot:parameter "username"))) (hunchentoot:start-session) (setf (hunchentoot:session-value 'sessu) username) (hunchentoot:session-value 'sessu))) (push (hunchentoot:create-prefix-dispatcher "/l" 'f) hunchentoot:*dispatch-table*) (push (hunchentoot:create-static-file-dispatcher-and-handler "/" "/Users/faruk/desktop/page.html") hunchentoot:*dispatch-table*) -------------- next part -------------- An HTML attachment was scrubbed... URL: From olegsivokon at gmail.com Sun Mar 2 07:30:00 2014 From: olegsivokon at gmail.com (Left Right) Date: Sun, 2 Mar 2014 09:30:00 +0200 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: References: <87FEC3A4-38B6-4384-89EA-BE41F44BA546@flownet.com> Message-ID: @Ron Garret I didn't mean HT own log, but even then locking isn't the best solution always: for example, I don't know what bordeaux-threads does when a thread holding a lock dies, does it release it? What if it depends on Lisp implementation? Maybe a lock-free queue would be a better option for log? - I don't know. Anyways, my point was that these would be non-trivial questions to answer, and while it is easy to come up with a simple SSE implementation, a real-world implementation might be a lot more difficult to master. Environments like PHP running as Apache httpd module don't have this problem, because they are single threaded, so, there it's a good (and, practically, only) choice. But it is good in a very limited sense... as it suffers from high congestion (something that concurrent execution is meant to address). A side note: SSE doesn't work (yet?) in Internet Explorer :) Well, I guess OP was already aware of it. @Hans H?bner I haven't tried it, but this is the quote from the front page of http://www.websocket.org/aboutwebsocket.html A WebSocket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT technique. [...] I'm not sure whether SSE can do the same and how well does this address the problem of proxies in general. From my experience using Flash sockets (they don't know how to tunnel over HTTP on their own), there was some obscure extension to HTTP 1.1 which allowed one to emulate simple TCP over HTTP :) I think that Adobe RTMP uses something like that as a fallback. As we actually had to use it (the product was an RP game, where many players were using computers behind NAT or some sort of corporative proxies, firewalls etc), we found that emulating TCP over HTTP in that way suited us better then other options we considered. On Sun, Mar 2, 2014 at 8:10 AM, Hans H?bner wrote: > While SSE wins over WebSockets in terms of simplicity, it should be noted > that intermediate http proxies may not deal with the protocol in the > required ways (i.e. the proxy may not forward the request until the whole > response has been read). One way around that is to use https, which will > implicitly make the proxy forward the connection directly to the origin > server, but may be forbidden by some proxies altogether. WebSockets share > the problem, but as they are defined a bit more strictly than SSE, they may > see more support in intermediate proxies. > > The only universally safe way to push events from a HTTP server to a client > is to use (long) polling. Other methods are not advisable if universal > availability of the service is desired. > > It is unfortunate that there is no maintained WebSockets service that works > well with Hunchentoot. There once was Hunchensocket, but it did not receive > any love over the last few years and thus requires considerable work to > bring it up to date. > > -Hans From ron at flownet.com Sat Mar 1 22:44:58 2014 From: ron at flownet.com (Ron Garret) Date: Sat, 1 Mar 2014 14:44:58 -0800 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: References: <87FEC3A4-38B6-4384-89EA-BE41F44BA546@flownet.com> Message-ID: If HT doesn?t have a mutex around log file writes that?s a bug in the HT logging code IMHO. Without a mutex, interleaved log file entries can happen even with ordinary HTTP requests. SSE has nothing to do with it. On Mar 1, 2014, at 2:30 PM, Left Right wrote: > It doesn't help if HT does it's part right. Imagine, for the sake of > argument that your code inside a handler writes to the log file. The > handle of the log file is shared between all threads (or else there > would be a log file per thread? Not something you want to do, right?). > So, imagine you have two long-living requests, which you serve in > server-events fashion: first starts writing to the file stream while > at the same time the second handles data. Just as the first one is > about to finish to write to the log, the second one finished writing > data and wants to write to the log as well: boom, you have a race: two > threads fighting over the ownership of the log file handle! > Sockets don't particularly help in this scenario, but IMO they make > the programmer more aware of what happens to the program (I'm not a > big fun of implicit parallelism...) > > On Sat, Mar 1, 2014 at 11:46 PM, Ron Garret wrote: >>> you may easily run yourself into a situation where two functions try to write to the same output stream >> >> >> I don't think so. The default HT taskmaster on a multi-threaded Lisp spawns a thread per connection and rebinds all the globals. If it didn't, then *any* simultaneous connections would have problems, not just SSE connections. And even on a single-threaded Lisp, subsequent requests would just be blocked until the SSE handler was done. That would certainly be a problem, but not the one you describe. >> >> rg >> >> On Mar 1, 2014, at 12:58 PM, Left Right wrote: >> >>> Don't forget that sockets are concurrent by design: in a simplest >>> scenario, you'd allocate a thread per connection. Not a very efficient >>> way of dealing with it, but at least it is easy to implement in a way >>> that you don't run into deadlocks or other errors caused by multiple >>> threads accessing shared state. But if you choose to use server >>> events, you would have to be very careful to write re-entrant >>> functions to serve the request, which is particularly difficult >>> because Hunchentoot relies on a handful of global variables to >>> function... you may easily run yourself into a situation where two >>> functions try to write to the same output stream, even at the level >>> that Unicode byte sequences become interleaved and the receiving side >>> would fail with arcane low-level decoding errors (happened to me >>> before). >>> >>> On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret wrote: >>>> Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is: >>>> >>>> var source=new EventSource(URL); >>>> source.onmessage=function(event) { do_something_with(event.data); } >>>> >>>> and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form: >>>> >>>> data: [your data] >>>> >>>> to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.) >>>> >>>> rg >>>> >>>> On Feb 28, 2014, at 1:40 PM, Left Right wrote: >>>> >>>>> Not exactly answering your question, but if you are looking for push >>>>> functionality in browser, then WebSockets might be a better option. >>>>> The reason server-sent events exist is by and large due to the >>>>> handicapped nature of most popular web-development stack in use today, >>>>> such as PHP interpreter that has to be started on every connection by >>>>> an HTTP server, such as Apache httpd or ngnx. This means that >>>>> traditional setup works in a stateless manner. This is unlike, say, >>>>> most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, >>>>> Tornado), where the setup is normally stateful, meaning that you >>>>> wouldn't need to restart the interpreter upon each request, instead, >>>>> your server would persist the state until it is shut down. Hunchentoot >>>>> belongs to the later category. >>>>> >>>>> Now, because it's not really possible to persist a PHP session across >>>>> multiple requests, a technique first known as long polling appeared. >>>>> The operating principle was that the server, in response to an HTTP >>>>> request would not close the connection immediately, instead it would >>>>> keep sending the information, whenever the application state at the >>>>> server would demand it. The receiving side (the browser) would listen >>>>> to updates on this connection and interpret them as "pushes". Event >>>>> stream is a refinement of this scheme. >>>>> >>>>> WebSockets, on the other hand, are plain TCP sockets, which means that >>>>> they don't require HTTP wrapping to function. I haven't had much >>>>> experience with JavaScript WebSockets, but I used their analogy in >>>>> Flash quite a bit. It was a relief not to depend on the bizarre rules >>>>> of HTTP protocol and its encodings, headers and so on. So I would >>>>> expect the same to hold for WebSockets. >>>>> >>>>> Best, >>>>> >>>>> Oleg >>>>> >>>>> On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can wrote: >>>>>> I have read in w3schools about usage of server sent events in html5. >>>>>> it says: >>>>>> >>>>>> Set the "Content-Type" header to "text/event-stream" >>>>>> Specify that the page should not cache >>>>>> Output the data to send (Always start with "data: ") >>>>>> >>>>>> that is in echo line in php code as echo "data: The server time is: >>>>>> {$time}\n\n"; >>>>>> >>>>>> Flush the output data back to the web page >>>>>> >>>>>> http://www.w3schools.com/html/html5_serversentevents.asp >>>>>> examples here are in php for server side. i am using hunchentoot on common >>>>>> lisp. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can wrote: >>>>>>> >>>>>>> I >>>>>>> have another question about hunchentoot. Is it possible to use server >>>>>>> sent events with hunchentoot, like other html5 improvements mentioned in >>>>>>> w3schools-html5 such as app cache, local storage, session storage? as that >>>>>>> one related to and depend on the server side support. >>>>>>> >>>>>> >>>>> >>>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From edi at agharta.de Thu Mar 20 08:37:56 2014 From: edi at agharta.de (Edi Weitz) Date: Thu, 20 Mar 2014 09:37:56 +0100 Subject: Another session problem In-Reply-To: <86y50546v1.fsf@math.fau.de> References: <86y50546v1.fsf@math.fau.de> Message-ID: The URL rewrite code should treate exactly like
(and that seems to work, at least for me). Is something else in your code (or maybe on the client side, with Javascript) manipulating the content? On Thu, Mar 20, 2014 at 9:22 AM, Nicolas Neuss wrote: > Hello, > > I have the following problem. > > Hunchentoot 1.2.26/SBCL 1.0.57 is serving pages from behind Apache. > More precisely, my Apache config is > > > ServerAdmin neuss at scipolis.de > ServerName yyy.math.fau.de > ServerAlias yyy.math.fau.de > > DocumentRoot /var/www > > Options FollowSymLinks > AllowOverride None > > > Options FollowSymLinks MultiViews > AllowOverride None > Order allow,deny > allow from all > > > ErrorLog ${APACHE_LOG_DIR}/error.log > ErrorDocument 404 /index.html > > ProxyRequests Off > ProxyPass /wissen http://localhost:8002 > ProxyPassReverse /wissen http://localhost:8002 > > > Now when accessing the page > > > > for the first time (!), the "form" gets an additional "action" parameter > which is an absolute path like > > > > while "href"s are (correctly) relative like > Informationen > > This leads to a wrong redirection when submitting the form. > > Is this a bug or is anything wrong with my setup? > > I'm using Hunchentoot 1.2.26 from Quicklisp. > > Thank you, > > Nicolas > > P.S.: If one refreshes the page after first access the action parameter > goes away and everything works as desired. Also with redirecting to the > login page I can remove this behaviour, but I would like to > understand what is going on here. > From ron at flownet.com Sat Mar 1 21:46:21 2014 From: ron at flownet.com (Ron Garret) Date: Sat, 1 Mar 2014 13:46:21 -0800 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: References: Message-ID: <87FEC3A4-38B6-4384-89EA-BE41F44BA546@flownet.com> > you may easily run yourself into a situation where two functions try to write to the same output stream I don?t think so. The default HT taskmaster on a multi-threaded Lisp spawns a thread per connection and rebinds all the globals. If it didn?t, then *any* simultaneous connections would have problems, not just SSE connections. And even on a single-threaded Lisp, subsequent requests would just be blocked until the SSE handler was done. That would certainly be a problem, but not the one you describe. rg On Mar 1, 2014, at 12:58 PM, Left Right wrote: > Don't forget that sockets are concurrent by design: in a simplest > scenario, you'd allocate a thread per connection. Not a very efficient > way of dealing with it, but at least it is easy to implement in a way > that you don't run into deadlocks or other errors caused by multiple > threads accessing shared state. But if you choose to use server > events, you would have to be very careful to write re-entrant > functions to serve the request, which is particularly difficult > because Hunchentoot relies on a handful of global variables to > function... you may easily run yourself into a situation where two > functions try to write to the same output stream, even at the level > that Unicode byte sequences become interleaved and the receiving side > would fail with arcane low-level decoding errors (happened to me > before). > > On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret wrote: >> Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is: >> >> var source=new EventSource(URL); >> source.onmessage=function(event) { do_something_with(event.data); } >> >> and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form: >> >> data: [your data] >> >> to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.) >> >> rg >> >> On Feb 28, 2014, at 1:40 PM, Left Right wrote: >> >>> Not exactly answering your question, but if you are looking for push >>> functionality in browser, then WebSockets might be a better option. >>> The reason server-sent events exist is by and large due to the >>> handicapped nature of most popular web-development stack in use today, >>> such as PHP interpreter that has to be started on every connection by >>> an HTTP server, such as Apache httpd or ngnx. This means that >>> traditional setup works in a stateless manner. This is unlike, say, >>> most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, >>> Tornado), where the setup is normally stateful, meaning that you >>> wouldn't need to restart the interpreter upon each request, instead, >>> your server would persist the state until it is shut down. Hunchentoot >>> belongs to the later category. >>> >>> Now, because it's not really possible to persist a PHP session across >>> multiple requests, a technique first known as long polling appeared. >>> The operating principle was that the server, in response to an HTTP >>> request would not close the connection immediately, instead it would >>> keep sending the information, whenever the application state at the >>> server would demand it. The receiving side (the browser) would listen >>> to updates on this connection and interpret them as "pushes". Event >>> stream is a refinement of this scheme. >>> >>> WebSockets, on the other hand, are plain TCP sockets, which means that >>> they don't require HTTP wrapping to function. I haven't had much >>> experience with JavaScript WebSockets, but I used their analogy in >>> Flash quite a bit. It was a relief not to depend on the bizarre rules >>> of HTTP protocol and its encodings, headers and so on. So I would >>> expect the same to hold for WebSockets. >>> >>> Best, >>> >>> Oleg >>> >>> On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can wrote: >>>> I have read in w3schools about usage of server sent events in html5. >>>> it says: >>>> >>>> Set the "Content-Type" header to "text/event-stream" >>>> Specify that the page should not cache >>>> Output the data to send (Always start with "data: ") >>>> >>>> that is in echo line in php code as echo "data: The server time is: >>>> {$time}\n\n"; >>>> >>>> Flush the output data back to the web page >>>> >>>> http://www.w3schools.com/html/html5_serversentevents.asp >>>> examples here are in php for server side. i am using hunchentoot on common >>>> lisp. >>>> >>>> >>>> >>>> On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can wrote: >>>>> >>>>> I >>>>> have another question about hunchentoot. Is it possible to use server >>>>> sent events with hunchentoot, like other html5 improvements mentioned in >>>>> w3schools-html5 such as app cache, local storage, session storage? as that >>>>> one related to and depend on the server side support. >>>>> >>>> >>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From neuss at scipolis.de Thu Mar 20 10:51:25 2014 From: neuss at scipolis.de (Nicolas Neuss) Date: Thu, 20 Mar 2014 11:51:25 +0100 Subject: Another session problem In-Reply-To: (Edi Weitz's message of "Thu, 20 Mar 2014 11:19:21 +0100") References: <86y50546v1.fsf@math.fau.de> <86k3bp44ca.fsf@math.fau.de> Message-ID: <86siqd16tu.fsf@math.fau.de> Somehow the slash is the problem, because it is interpreted (at least my Firefox does it, as well as my Konqueror) as >> http://yyy.math.fau.de/admin-login?nr=4 instead of >> http://yyy.math.fau.de/wissen/admin-login?nr=4 while the link without the slash is interpreted as desired. It is very unclear to me which software is to blame. More precisely, I see the following possibilities: 1. The Apache proxy module for not translating the absolute path starting with slash correctly into a path containing '.../wissen/...' 2. My configuration of that module: ... ProxyRequests Off ProxyPass /wissen http://localhost:8002 ProxyPassReverse /wissen http://localhost:8002 ... 3. Whatever code inserts the "action" parameter in the first place. (I don't have this "action" in my template, which is processed by HTML-TEMPLATE, URL-REWRITE, HUNCHENTOOT, ...) Thanks, Nicolas Edi Weitz writes: > The only difference I can see in your email is the slash. That's > something that shouldn't be affected by URL rewriting at all. > > I'm attaching the HTML page I received when I viewed your URL for the > first time (using Firefox). > > > > On Thu, Mar 20, 2014 at 10:16 AM, Nicolas Neuss wrote: >> Edi Weitz writes: >> >>> The URL rewrite code should treate exactly like >> ACTION ...> (and that seems to work, at least for me). Is something >>> else in your code (or maybe on the client side, with Javascript) >>> manipulating the content? >> >> Hi Edi, >> >> does that means that if you access my URL >> >> http://yyy.math.fau.de/wissen/admin-login?nr=4 >> >> for the first time, the downloaded page source contains a line like >> >> >> >> instead of >> >> >> ^ >> ! >> >> ?? >> >> Thanks for the feedback, >> >> Nicolas >> > -- Nicolas Neuss neuss at math.fau.de From olegsivokon at gmail.com Sat Mar 1 22:30:48 2014 From: olegsivokon at gmail.com (Left Right) Date: Sun, 2 Mar 2014 00:30:48 +0200 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: <87FEC3A4-38B6-4384-89EA-BE41F44BA546@flownet.com> References: <87FEC3A4-38B6-4384-89EA-BE41F44BA546@flownet.com> Message-ID: It doesn't help if HT does it's part right. Imagine, for the sake of argument that your code inside a handler writes to the log file. The handle of the log file is shared between all threads (or else there would be a log file per thread? Not something you want to do, right?). So, imagine you have two long-living requests, which you serve in server-events fashion: first starts writing to the file stream while at the same time the second handles data. Just as the first one is about to finish to write to the log, the second one finished writing data and wants to write to the log as well: boom, you have a race: two threads fighting over the ownership of the log file handle! Sockets don't particularly help in this scenario, but IMO they make the programmer more aware of what happens to the program (I'm not a big fun of implicit parallelism...) On Sat, Mar 1, 2014 at 11:46 PM, Ron Garret wrote: >> you may easily run yourself into a situation where two functions try to write to the same output stream > > > I don't think so. The default HT taskmaster on a multi-threaded Lisp spawns a thread per connection and rebinds all the globals. If it didn't, then *any* simultaneous connections would have problems, not just SSE connections. And even on a single-threaded Lisp, subsequent requests would just be blocked until the SSE handler was done. That would certainly be a problem, but not the one you describe. > > rg > > On Mar 1, 2014, at 12:58 PM, Left Right wrote: > >> Don't forget that sockets are concurrent by design: in a simplest >> scenario, you'd allocate a thread per connection. Not a very efficient >> way of dealing with it, but at least it is easy to implement in a way >> that you don't run into deadlocks or other errors caused by multiple >> threads accessing shared state. But if you choose to use server >> events, you would have to be very careful to write re-entrant >> functions to serve the request, which is particularly difficult >> because Hunchentoot relies on a handful of global variables to >> function... you may easily run yourself into a situation where two >> functions try to write to the same output stream, even at the level >> that Unicode byte sequences become interleaved and the receiving side >> would fail with arcane low-level decoding errors (happened to me >> before). >> >> On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret wrote: >>> Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is: >>> >>> var source=new EventSource(URL); >>> source.onmessage=function(event) { do_something_with(event.data); } >>> >>> and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form: >>> >>> data: [your data] >>> >>> to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.) >>> >>> rg >>> >>> On Feb 28, 2014, at 1:40 PM, Left Right wrote: >>> >>>> Not exactly answering your question, but if you are looking for push >>>> functionality in browser, then WebSockets might be a better option. >>>> The reason server-sent events exist is by and large due to the >>>> handicapped nature of most popular web-development stack in use today, >>>> such as PHP interpreter that has to be started on every connection by >>>> an HTTP server, such as Apache httpd or ngnx. This means that >>>> traditional setup works in a stateless manner. This is unlike, say, >>>> most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, >>>> Tornado), where the setup is normally stateful, meaning that you >>>> wouldn't need to restart the interpreter upon each request, instead, >>>> your server would persist the state until it is shut down. Hunchentoot >>>> belongs to the later category. >>>> >>>> Now, because it's not really possible to persist a PHP session across >>>> multiple requests, a technique first known as long polling appeared. >>>> The operating principle was that the server, in response to an HTTP >>>> request would not close the connection immediately, instead it would >>>> keep sending the information, whenever the application state at the >>>> server would demand it. The receiving side (the browser) would listen >>>> to updates on this connection and interpret them as "pushes". Event >>>> stream is a refinement of this scheme. >>>> >>>> WebSockets, on the other hand, are plain TCP sockets, which means that >>>> they don't require HTTP wrapping to function. I haven't had much >>>> experience with JavaScript WebSockets, but I used their analogy in >>>> Flash quite a bit. It was a relief not to depend on the bizarre rules >>>> of HTTP protocol and its encodings, headers and so on. So I would >>>> expect the same to hold for WebSockets. >>>> >>>> Best, >>>> >>>> Oleg >>>> >>>> On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can wrote: >>>>> I have read in w3schools about usage of server sent events in html5. >>>>> it says: >>>>> >>>>> Set the "Content-Type" header to "text/event-stream" >>>>> Specify that the page should not cache >>>>> Output the data to send (Always start with "data: ") >>>>> >>>>> that is in echo line in php code as echo "data: The server time is: >>>>> {$time}\n\n"; >>>>> >>>>> Flush the output data back to the web page >>>>> >>>>> http://www.w3schools.com/html/html5_serversentevents.asp >>>>> examples here are in php for server side. i am using hunchentoot on common >>>>> lisp. >>>>> >>>>> >>>>> >>>>> On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can wrote: >>>>>> >>>>>> I >>>>>> have another question about hunchentoot. Is it possible to use server >>>>>> sent events with hunchentoot, like other html5 improvements mentioned in >>>>>> w3schools-html5 such as app cache, local storage, session storage? as that >>>>>> one related to and depend on the server side support. >>>>>> >>>>> >>>> >>> > From neuss at scipolis.de Fri Mar 21 04:13:54 2014 From: neuss at scipolis.de (Nicolas Neuss) Date: Fri, 21 Mar 2014 05:13:54 +0100 Subject: Another session problem In-Reply-To: (Edi Weitz's message of "Thu, 20 Mar 2014 12:01:49 +0100") References: <86y50546v1.fsf@math.fau.de> <86k3bp44ca.fsf@math.fau.de> <86siqd16tu.fsf@math.fau.de> Message-ID: <86eh1wxk71.fsf@math.fau.de> Edi Weitz writes: > On Thu, Mar 20, 2014 at 11:51 AM, Nicolas Neuss wrote: >> ProxyRequests Off >> ProxyPass /wissen http://localhost:8002 >> ProxyPassReverse /wissen http://localhost:8002 > > I'd replace /wissen with /wissen/ and :8002 with :8002/ in both cases. > That's what I do in my apps. (But then URLs ending in ".../wissen" > won't work anymore if that's a problem for you. (Which you could in > turn fix with mod_rewrite, hehe...)) I tried this just now. However, the behavior stayed the same, so I reverted that change. > Otherwise, as Hans already said, set *REWRITE-FOR-SESSION-URLS* to NIL > if you don't need cookie-less sessions. Yes, this helps. Thank you (and thank you Hans). > That would be two possible sources for errors. > > (And, yes, Hunchentoot indeed adds the ACTION parameter. This > behavior is controlled by url-rewrite:*url-rewrite-fill-tags* but you > won't see it anymore if you set the variable mentioned above to NIL.) OK. Of course, I would prefer to have it working also for those who forbid cookies. But I guess that there won't be many such people nowadays. [I had found the *url-rewrite-fill-tags* and the place where it was used in url-rewrite.lisp already. But the code following is quite opaque to me, i.e. I didn't yet see where the slashed value '/admin-login?nr=4&hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42' for the "action" parameter which I mentioned in my previous post is generated. Now I think I found it: it is (REQUEST-URI *REQUEST*) in the function ADD-COOKIE-VALUE-TO-URL in hunchentoot/misc.lisp.] Nicolas P.S.: It's 5 am here. I could not sleep so I looked at this again, but now I'll try to take another nap until I really have to get up. From josrr at ymail.com Thu Mar 20 22:09:43 2014 From: josrr at ymail.com (=?iso-8859-1?Q?Jos=E9_Ronquillo?=) Date: Thu, 20 Mar 2014 15:09:43 -0700 (PDT) Subject: yet another session problem In-Reply-To: References: Message-ID: <1395353383.82921.YahooMailNeo@web122901.mail.ne1.yahoo.com> Hello again Faruk, I think the symbol *session* is not bound immediately after calling the function start-session, but the function returns it; this code works: (defun f () ? (let ((username (hunchentoot:parameter "username")) (session (hunchentoot:start-session))) ? ? (format t "session:~s~%" session) ? ? (setf (hunchentoot:session-value 'sessu session) username) ? ? (hunchentoot:session-value 'sessu session))) On Thursday, March 20, 2014 3:29 PM, Faruk S. Can wrote: and with page.html: 2014-03-20 23:08 GMT+02:00 Faruk S. Can : no offense. >I need help on hunchentoot session topic. >whether I am doing a very simple mistake, >or there is an issue. >I do not need do not send your code >and beg for help to solicit help >as somebody has told days before >this is very basically should work as I am expecting. >It is very simple. >to ensure installs are done: > > >(ql:quickload '(:hunchentoot)) > >(hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 5050)) > > > >(defun f () >? (let ((username (hunchentoot:parameter "username"))) >? ? (hunchentoot:start-session) >? ? (setf (hunchentoot:session-value 'sessu) username) >? ? (hunchentoot:session-value 'sessu))) > > >(push (hunchentoot:create-prefix-dispatcher "/l" 'f) hunchentoot:*dispatch-table*) > > > >(push (hunchentoot:create-static-file-dispatcher-and-handler "/" "/Users/faruk/desktop/page.html") hunchentoot:*dispatch-table*) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farukscan at gmail.com Thu Mar 20 21:12:10 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Thu, 20 Mar 2014 23:12:10 +0200 Subject: yet another session problem In-Reply-To: References: Message-ID: alt console log: 127.0.0.1 - [2014-03-20 23:10:47] "GET / HTTP/1.1" 200 145 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" [2014-03-20 23:10:51 [ERROR]] (SESSU . hjkl) 127.0.0.1 - [2014-03-20 23:10:51] "GET /l?username=hjkl HTTP/1.1" 500 343 " http://localhost:4040/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" On Thu, Mar 20, 2014 at 11:09 PM, Faruk S. Can wrote: > and with page.html: > > >
> > >
> > > > > 2014-03-20 23:08 GMT+02:00 Faruk S. Can : > > no offense. >> I need help on hunchentoot session topic. >> whether I am doing a very simple mistake, >> or there is an issue. >> I do not need do not send your code >> and beg for help to solicit help >> as somebody has told days before >> this is very basically should work as I am expecting. >> It is very simple. >> to ensure installs are done: >> >> (ql:quickload '(:hunchentoot)) >> (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 5050)) >> >> (defun f () >> (let ((username (hunchentoot:parameter "username"))) >> (hunchentoot:start-session) >> (setf (hunchentoot:session-value 'sessu) username) >> (hunchentoot:session-value 'sessu))) >> >> (push (hunchentoot:create-prefix-dispatcher "/l" 'f) >> hunchentoot:*dispatch-table*) >> >> (push (hunchentoot:create-static-file-dispatcher-and-handler "/" >> "/Users/faruk/desktop/page.html") hunchentoot:*dispatch-table*) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at flownet.com Sat Mar 1 22:25:27 2014 From: ron at flownet.com (Ron Garret) Date: Sat, 1 Mar 2014 14:25:27 -0800 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: <2E11223E-3250-4B6C-931E-43ED4B246E62@pobox.com> References: <2E11223E-3250-4B6C-931E-43ED4B246E62@pobox.com> Message-ID: On Mar 1, 2014, at 2:01 PM, Ben Hyde wrote: > On Mar 1, 2014, at 3:04 PM, Ron Garret wrote: >> server-side events > > I assume, you cobbled together your own Hunchentoot compatible implementation? Or, is there one kicking about I've not noticed? - ben Here?s a self-contained SSE demo: (require :hunchentoot) (rename-package :hunchentoot :hunchentoot '(:tbnl :ht)) (defvar $server (make-instance 'ht::easy-acceptor :port 1234 :access-log-destination nil)) (ht:start $server) (ht:define-easy-handler (sse-test :uri "/sse-test") () " Server-side event demo
") (defun set-header (name value) (setf (ht:header-out name) value)) (ht:define-easy-handler (sse-stream :uri "/sse-stream") () (set-header "content-type" "text/event-stream") (set-header "cache-control" "no-cache") (let ((stream (ht:send-headers))) (dotimes (i 10) (write-sequence (encode-string-to-octets (format nil "data: test ~A~A~A" i #\newline #\newline)) stream) (force-output stream) (sleep 0.5)))) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rwiker at gmail.com Sun Mar 9 20:20:35 2014 From: rwiker at gmail.com (Raymond Wiker) Date: Sun, 9 Mar 2014 21:20:35 +0100 Subject: In-Reply-To: References: Message-ID: I'd say that your two obvious options are to use references that Hunchentoot has been configured to resolve, or to configure Hunchentoot to handle the urls that you want to use. In case that wasn't clear enough: the mechanisms that you use to tell Hunchentoot where to find "/test" will not automatically figure out what you mean by "/~/mystyle.css". On 09 Mar 2014, at 21:10 , Faruk S. Can wrote: > maybe comic enough but i cannot serve an html file that is linked to css file. > > test.html > > > > > > > > asdf > > > > > mystyle.css > > body > { > background-color:tan; > } > > this html is rendered when i double click it. > but i cannot serve it with style aded. > alt console says: > 127.0.0.1 - [2014-03-09 22:09:46] "GET /test HTTP/1.1" 200 114 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" > 127.0.0.1 - [2014-03-09 22:09:46] "GET /~/mystyle.css HTTP/1.1" 404 360 "http://localhost:5050/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" > > What should i do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From neuss at scipolis.de Thu Mar 20 08:22:26 2014 From: neuss at scipolis.de (Nicolas Neuss) Date: Thu, 20 Mar 2014 09:22:26 +0100 Subject: Another session problem Message-ID: <86y50546v1.fsf@math.fau.de> Hello, I have the following problem. Hunchentoot 1.2.26/SBCL 1.0.57 is serving pages from behind Apache. More precisely, my Apache config is ServerAdmin neuss at scipolis.de ServerName yyy.math.fau.de ServerAlias yyy.math.fau.de DocumentRoot /var/www Options FollowSymLinks AllowOverride None Options FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all ErrorLog ${APACHE_LOG_DIR}/error.log ErrorDocument 404 /index.html ProxyRequests Off ProxyPass /wissen http://localhost:8002 ProxyPassReverse /wissen http://localhost:8002 Now when accessing the page for the first time (!), the "form" gets an additional "action" parameter which is an absolute path like
while "href"s are (correctly) relative like Informationen This leads to a wrong redirection when submitting the form. Is this a bug or is anything wrong with my setup? I'm using Hunchentoot 1.2.26 from Quicklisp. Thank you, Nicolas P.S.: If one refreshes the page after first access the action parameter goes away and everything works as desired. Also with redirecting to the login page I can remove this behaviour, but I would like to understand what is going on here. From neuss at scipolis.de Thu Mar 20 09:16:53 2014 From: neuss at scipolis.de (Nicolas Neuss) Date: Thu, 20 Mar 2014 10:16:53 +0100 Subject: Another session problem In-Reply-To: (Edi Weitz's message of "Thu, 20 Mar 2014 09:37:56 +0100") References: <86y50546v1.fsf@math.fau.de> Message-ID: <86k3bp44ca.fsf@math.fau.de> Edi Weitz writes: > The URL rewrite code should treate exactly like ACTION ...> (and that seems to work, at least for me). Is something > else in your code (or maybe on the client side, with Javascript) > manipulating the content? Hi Edi, does that means that if you access my URL http://yyy.math.fau.de/wissen/admin-login?nr=4 for the first time, the downloaded page source contains a line like instead of ^ ! ?? Thanks for the feedback, Nicolas From hans.huebner at gmail.com Thu Mar 20 08:43:13 2014 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 20 Mar 2014 09:43:13 +0100 Subject: Another session problem In-Reply-To: <86y50546v1.fsf@math.fau.de> References: <86y50546v1.fsf@math.fau.de> Message-ID: Hi Nicolas, what you're seeing is Hunchentoot rewriting the contents of forms so that a session ID parameter is automagically added to forms for clients that do not have cookies enabled. The documentation mentions that this is done unless *rewrite-for-session-urls* is NIL. I am not sure whether the functionality is working all that well, as I have not been using it in the past. If you do not need to support sessions without cookies, I'd recommend that you disable the functionality. If you do need it, it would be helpful if you could debug some more to pinpoint where the behavior is actually wrong. Thanks, Hans 2014-03-20 9:22 GMT+01:00 Nicolas Neuss : > Hello, > > I have the following problem. > > Hunchentoot 1.2.26/SBCL 1.0.57 is serving pages from behind Apache. > More precisely, my Apache config is > > > ServerAdmin neuss at scipolis.de > ServerName yyy.math.fau.de > ServerAlias yyy.math.fau.de > > DocumentRoot /var/www > > Options FollowSymLinks > AllowOverride None > > > Options FollowSymLinks MultiViews > AllowOverride None > Order allow,deny > allow from all > > > ErrorLog ${APACHE_LOG_DIR}/error.log > ErrorDocument 404 /index.html > > ProxyRequests Off > ProxyPass /wissen http://localhost:8002 > ProxyPassReverse /wissen http://localhost:8002 > > > Now when accessing the page > > > > for the first time (!), the "form" gets an additional "action" parameter > which is an absolute path like > > action='/admin-login?nr=4&hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42'> > > while "href"s are (correctly) relative like > href='about?hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42'>Informationen > > This leads to a wrong redirection when submitting the form. > > Is this a bug or is anything wrong with my setup? > > I'm using Hunchentoot 1.2.26 from Quicklisp. > > Thank you, > > Nicolas > > P.S.: If one refreshes the page after first access the action parameter > goes away and everything works as desired. Also with redirecting to the > login page I can remove this behaviour, but I would like to > understand what is going on here. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farukscan at gmail.com Wed Mar 12 17:19:09 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Wed, 12 Mar 2014 19:19:09 +0200 Subject: sessions Message-ID: hi i cannot sustain a session. i login to my app. it shows my login name as i programmed. when i refresh the page it stays there. but when i refresh for the second time my session name and other things goes away and instead i see what is there for the not loginned case. I think i miss something in hunchentoot session hadling. ;all html generated by a macro: (defmacro ff (tag) `(defun ,tag (&rest c) (with-output-to-string (*standard-output*) (format t "<~a ~{~a='~a' ~}> ~{~a ~}" ',tag (car c) (cdr c) ',tag)))) ;;defining all tag functions: (progn (ff html) (ff title) (ff head) (ff meta) (ff link) (ff style) (ff script) (ff body) (ff span) (ff div) (ff section) (ff p) (ff form) (ff input) (ff button) (ff textarea) (ff a) (ff h1) (ff h2) (ff h3) (ff h4) (ff h5) (ff h6) (ff ol) (ff ul) (ff li)) ;authentication utilities used by the home page function at the bottom: (defun signed-in-p () (if (and (boundp '*session*) (session-value '*signed-in *session*)) t nil)) (defun signed-up-p (x y) (if (with-connection *conn1spec* (query (:select 'username 'password :from 'users.users :where (:and (:= 'username x) (:= 'password y))))) t nil)) (defun sign-in () (let ((username (parameter "username")) (password (parameter "password"))) (if (signed-up-p username password) (progn (start-session) (setf (session-value '*username) username) (setf (session-value '*signed-in) t) (morph-status-plate (session-value '*username))) (with-output-to-string (s) (princ (morph-sign-in-form) s) (princ "No record found!" s) (princ (a (list :href "/form-sign-up") "Sign up") s) )))) ;the data base querying functions are working correctly ;views generated: (defun morph-write-button () (div (list :style "border:1px solid; float:left;") (a (list :href "/writingp") "write"))) (defun morph-status-plate (username) (div (list :id "status-plate" :style "border:1px solid; float:left;") (span () "123 users online") (span () username) (button (list :onclick "ajaxlogout()") "logout"))) (defun morph-sign-in-form () (div (list :id "sign-in-form" :style "border:1px solid; float:left;") (form (list :method "" :action "") (input (list :id "username" :type "input" :name "username")) (input (list :id "password" :type "input" :name "password")) (input (list :onClick "ajaxsignin()" :type "button" :value "login"))))) ;at last ;the page i generate as home page: (div (list :id "sign-in-form-or-status-plate" :style "height: 45px; border: 1px solid; float:left;") (if (signed-in-p);;;;;; (with-output-to-string (s) (start-session) (princ (morph-status-plate (session-value '*username)) s) (princ (morph-write-button) s)) (with-output-to-string (s) (princ (morph-sign-in-form) s) (princ (a (list :href "form-sign-up") "Sign up") s)))) -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Thu Mar 20 10:19:21 2014 From: edi at agharta.de (Edi Weitz) Date: Thu, 20 Mar 2014 11:19:21 +0100 Subject: Another session problem In-Reply-To: <86k3bp44ca.fsf@math.fau.de> References: <86y50546v1.fsf@math.fau.de> <86k3bp44ca.fsf@math.fau.de> Message-ID: The only difference I can see in your email is the slash. That's something that shouldn't be affected by URL rewriting at all. I'm attaching the HTML page I received when I viewed your URL for the first time (using Firefox). On Thu, Mar 20, 2014 at 10:16 AM, Nicolas Neuss wrote: > Edi Weitz writes: > >> The URL rewrite code should treate exactly like > ACTION ...> (and that seems to work, at least for me). Is something >> else in your code (or maybe on the client side, with Javascript) >> manipulating the content? > > Hi Edi, > > does that means that if you access my URL > > http://yyy.math.fau.de/wissen/admin-login?nr=4 > > for the first time, the downloaded page source contains a line like > > > > instead of > > > ^ > ! > > ?? > > Thanks for the feedback, > > Nicolas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Sun Mar 2 06:10:12 2014 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 2 Mar 2014 07:10:12 +0100 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: References: <87FEC3A4-38B6-4384-89EA-BE41F44BA546@flownet.com> Message-ID: While SSE wins over WebSockets in terms of simplicity, it should be noted that intermediate http proxies may not deal with the protocol in the required ways (i.e. the proxy may not forward the request until the whole response has been read). One way around that is to use https, which will implicitly make the proxy forward the connection directly to the origin server, but may be forbidden by some proxies altogether. WebSockets share the problem, but as they are defined a bit more strictly than SSE, they may see more support in intermediate proxies. The only universally safe way to push events from a HTTP server to a client is to use (long) polling. Other methods are not advisable if universal availability of the service is desired. It is unfortunate that there is no maintained WebSockets service that works well with Hunchentoot. There once was Hunchensocket, but it did not receive any love over the last few years and thus requires considerable work to bring it up to date. -Hans -------------- next part -------------- An HTML attachment was scrubbed... URL: From josrr at ymail.com Thu Mar 20 22:12:15 2014 From: josrr at ymail.com (=?iso-8859-1?Q?Jos=E9_Ronquillo?=) Date: Thu, 20 Mar 2014 15:12:15 -0700 (PDT) Subject: yet another session problem In-Reply-To: <1395353383.82921.YahooMailNeo@web122901.mail.ne1.yahoo.com> References: <1395353383.82921.YahooMailNeo@web122901.mail.ne1.yahoo.com> Message-ID: <1395353535.51893.YahooMailNeo@web122906.mail.ne1.yahoo.com> Ok, it still reports the error to the browser, but the session is created and the session value is saved. On , Jos? Ronquillo wrote: Hello again Faruk, I think the symbol *session* is not bound immediately after calling the function start-session, but the function returns it; this code works: (defun f () ? (let ((username (hunchentoot:parameter "username")) (session (hunchentoot:start-session))) ? ? (format t "session:~s~%" session) ? ? (setf (hunchentoot:session-value 'sessu session) username) ? ? (hunchentoot:session-value 'sessu session))) On Thursday, March 20, 2014 3:29 PM, Faruk S. Can wrote: and with page.html: 2014-03-20 23:08 GMT+02:00 Faruk S. Can : no offense. >I need help on hunchentoot session topic. >whether I am doing a very simple mistake, >or there is an issue. >I do not need do not send your code >and beg for help to solicit help >as somebody has told days before >this is very basically should work as I am expecting. >It is very simple. >to ensure installs are done: > > >(ql:quickload '(:hunchentoot)) > >(hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 5050)) > > > >(defun f () >? (let ((username (hunchentoot:parameter "username"))) >? ? (hunchentoot:start-session) >? ? (setf (hunchentoot:session-value 'sessu) username) >? ? (hunchentoot:session-value 'sessu))) > > >(push (hunchentoot:create-prefix-dispatcher "/l" 'f) hunchentoot:*dispatch-table*) > > > >(push (hunchentoot:create-static-file-dispatcher-and-handler "/" "/Users/faruk/desktop/page.html") hunchentoot:*dispatch-table*) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farukscan at gmail.com Sat Mar 15 17:40:14 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Sat, 15 Mar 2014 19:40:14 +0200 Subject: sessions In-Reply-To: References: Message-ID: my problem persists. once it has gone but i could not figure out how. but now the problem is back. any help? On Wed, Mar 12, 2014 at 7:19 PM, Faruk S. Can wrote: > hi > i cannot sustain a session. > i login to my app. it shows my login name as i programmed. > when i refresh the page it stays there. > but when i refresh for the second time my session name and > other things goes away and instead i see what is there for the > not loginned case. > > I think i miss something in hunchentoot session hadling. > > ;all html generated by a macro: > > (defmacro ff (tag) > `(defun ,tag (&rest c) > (with-output-to-string (*standard-output*) > (format t "<~a ~{~a='~a' ~}> ~{~a ~}" ',tag (car c) (cdr c) > ',tag)))) > > ;;defining all tag functions: > (progn > (ff html) > (ff title) > (ff head) > (ff meta) > (ff link) > (ff style) > (ff script) > (ff body) > (ff span) > (ff div) > (ff section) > (ff p) > (ff form) > (ff input) > (ff button) > (ff textarea) > (ff a) > (ff h1) > (ff h2) > (ff h3) > (ff h4) > (ff h5) > (ff h6) > (ff ol) > (ff ul) > (ff li)) > > ;authentication utilities used by the home page function at the bottom: > > (defun signed-in-p () > (if (and (boundp '*session*) (session-value '*signed-in *session*)) > t > nil)) > > (defun signed-up-p (x y) > (if (with-connection *conn1spec* > (query (:select 'username 'password :from 'users.users > :where (:and (:= 'username x) > (:= 'password y))))) > t > nil)) > > (defun sign-in () > (let ((username (parameter "username")) > (password (parameter "password"))) > (if (signed-up-p username password) > (progn > (start-session) > (setf (session-value '*username) username) > (setf (session-value '*signed-in) t) > (morph-status-plate (session-value '*username))) > (with-output-to-string (s) > (princ (morph-sign-in-form) s) > (princ "No record found!" s) > (princ (a (list :href "/form-sign-up") "Sign up") s) > )))) > ;the data base querying functions are working correctly > ;views generated: > > (defun morph-write-button () > (div (list :style "border:1px solid; float:left;") > (a (list :href "/writingp") "write"))) > > (defun morph-status-plate (username) > (div (list :id "status-plate" :style "border:1px solid; float:left;") > (span () "123 users online") > (span () username) > (button (list :onclick "ajaxlogout()") "logout"))) > > (defun morph-sign-in-form () > (div (list :id "sign-in-form" :style "border:1px solid; float:left;") > (form (list :method "" :action "") > (input (list :id "username" :type "input" :name "username")) > (input (list :id "password" :type "input" :name "password")) > (input (list :onClick "ajaxsignin()" :type "button" :value "login"))))) > > ;at last > ;the page i generate as home page: > (div (list :id "sign-in-form-or-status-plate" > :style "height: 45px; border: 1px solid; > float:left;") > (if (signed-in-p);;;;;; > (with-output-to-string (s) > (start-session) > (princ (morph-status-plate (session-value '*username)) > s) > (princ (morph-write-button) s)) > (with-output-to-string (s) > (princ (morph-sign-in-form) s) > (princ (a (list :href "form-sign-up") "Sign up") s)))) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Thu Mar 20 08:48:59 2014 From: edi at agharta.de (Edi Weitz) Date: Thu, 20 Mar 2014 09:48:59 +0100 Subject: Another session problem In-Reply-To: References: <86y50546v1.fsf@math.fau.de> Message-ID: On Thu, Mar 20, 2014 at 9:43 AM, Hans H?bner wrote: > I am not sure whether the functionality is working all that well It works fine. Here's an app that is used by my students almost every day: http://weitz.de/mars/ Click on the link above and look at the source code. You should see that the
part is properly rewritten. Cheers, Edi. From ron at flownet.com Sat Mar 1 20:04:45 2014 From: ron at flownet.com (Ron Garret) Date: Sat, 1 Mar 2014 12:04:45 -0800 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: References: Message-ID: Personally I much prefer server-side events (SSE). It?s a lot simpler than websockets. On the client side all you do is: var source=new EventSource(URL); source.onmessage=function(event) { do_something_with(event.data); } and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form: data: [your data] to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that?s the only complication.) rg On Feb 28, 2014, at 1:40 PM, Left Right wrote: > Not exactly answering your question, but if you are looking for push > functionality in browser, then WebSockets might be a better option. > The reason server-sent events exist is by and large due to the > handicapped nature of most popular web-development stack in use today, > such as PHP interpreter that has to be started on every connection by > an HTTP server, such as Apache httpd or ngnx. This means that > traditional setup works in a stateless manner. This is unlike, say, > most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, > Tornado), where the setup is normally stateful, meaning that you > wouldn't need to restart the interpreter upon each request, instead, > your server would persist the state until it is shut down. Hunchentoot > belongs to the later category. > > Now, because it's not really possible to persist a PHP session across > multiple requests, a technique first known as long polling appeared. > The operating principle was that the server, in response to an HTTP > request would not close the connection immediately, instead it would > keep sending the information, whenever the application state at the > server would demand it. The receiving side (the browser) would listen > to updates on this connection and interpret them as "pushes". Event > stream is a refinement of this scheme. > > WebSockets, on the other hand, are plain TCP sockets, which means that > they don't require HTTP wrapping to function. I haven't had much > experience with JavaScript WebSockets, but I used their analogy in > Flash quite a bit. It was a relief not to depend on the bizarre rules > of HTTP protocol and its encodings, headers and so on. So I would > expect the same to hold for WebSockets. > > Best, > > Oleg > > On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can wrote: >> I have read in w3schools about usage of server sent events in html5. >> it says: >> >> Set the "Content-Type" header to "text/event-stream" >> Specify that the page should not cache >> Output the data to send (Always start with "data: ") >> >> that is in echo line in php code as echo "data: The server time is: >> {$time}\n\n"; >> >> Flush the output data back to the web page >> >> http://www.w3schools.com/html/html5_serversentevents.asp >> examples here are in php for server side. i am using hunchentoot on common >> lisp. >> >> >> >> On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can wrote: >>> >>> I >>> have another question about hunchentoot. Is it possible to use server >>> sent events with hunchentoot, like other html5 improvements mentioned in >>> w3schools-html5 such as app cache, local storage, session storage? as that >>> one related to and depend on the server side support. >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From farukscan at gmail.com Thu Mar 20 21:12:49 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Thu, 20 Mar 2014 23:12:49 +0200 Subject: yet another session problem In-Reply-To: References: Message-ID: On browser: 500 Internal Server Error. On Thu, Mar 20, 2014 at 11:12 PM, Faruk S. Can wrote: > alt console log: > > 127.0.0.1 - [2014-03-20 23:10:47] "GET / HTTP/1.1" 200 145 "-" > "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 > (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" > [2014-03-20 23:10:51 [ERROR]] (SESSU . hjkl) > 127.0.0.1 - [2014-03-20 23:10:51] "GET /l?username=hjkl HTTP/1.1" 500 343 " > http://localhost:4040/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) > AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" > > > On Thu, Mar 20, 2014 at 11:09 PM, Faruk S. Can wrote: > >> and with page.html: >> >> >> >> >> >> >> >> >> >> >> 2014-03-20 23:08 GMT+02:00 Faruk S. Can : >> >> no offense. >>> I need help on hunchentoot session topic. >>> whether I am doing a very simple mistake, >>> or there is an issue. >>> I do not need do not send your code >>> and beg for help to solicit help >>> as somebody has told days before >>> this is very basically should work as I am expecting. >>> It is very simple. >>> to ensure installs are done: >>> >>> (ql:quickload '(:hunchentoot)) >>> (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 5050)) >>> >>> (defun f () >>> (let ((username (hunchentoot:parameter "username"))) >>> (hunchentoot:start-session) >>> (setf (hunchentoot:session-value 'sessu) username) >>> (hunchentoot:session-value 'sessu))) >>> >>> (push (hunchentoot:create-prefix-dispatcher "/l" 'f) >>> hunchentoot:*dispatch-table*) >>> >>> (push (hunchentoot:create-static-file-dispatcher-and-handler "/" >>> "/Users/faruk/desktop/page.html") hunchentoot:*dispatch-table*) >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Sun Mar 23 00:43:10 2014 From: edi at agharta.de (Edi Weitz) Date: Sun, 23 Mar 2014 01:43:10 +0100 Subject: Another session problem In-Reply-To: <86eh1wxk71.fsf@math.fau.de> References: <86y50546v1.fsf@math.fau.de> <86k3bp44ca.fsf@math.fau.de> <86siqd16tu.fsf@math.fau.de> <86eh1wxk71.fsf@math.fau.de> Message-ID: On Fri, Mar 21, 2014 at 5:13 AM, Nicolas Neuss wrote: > Of course, I would prefer to have it working also for those who > forbid cookies. I think the best way to achieve this is to create your own (correct) ACTION parameter and then to re-enable URL rewriting. From farukscan at gmail.com Sun Mar 9 20:10:40 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Sun, 9 Mar 2014 22:10:40 +0200 Subject: No subject Message-ID: maybe comic enough but i cannot serve an html file that is linked to css file. test.html asdf mystyle.css body { background-color:tan; } this html is rendered when i double click it. but i cannot serve it with style aded. alt console says: 127.0.0.1 - [2014-03-09 22:09:46] "GET /test HTTP/1.1" 200 114 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" 127.0.0.1 - [2014-03-09 22:09:46] "GET /~/mystyle.css HTTP/1.1" 404 360 " http://localhost:5050/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" What should i do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From farukscan at gmail.com Thu Mar 20 21:09:54 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Thu, 20 Mar 2014 23:09:54 +0200 Subject: yet another session problem In-Reply-To: References: Message-ID: and with page.html:
2014-03-20 23:08 GMT+02:00 Faruk S. Can : > no offense. > I need help on hunchentoot session topic. > whether I am doing a very simple mistake, > or there is an issue. > I do not need do not send your code > and beg for help to solicit help > as somebody has told days before > this is very basically should work as I am expecting. > It is very simple. > to ensure installs are done: > > (ql:quickload '(:hunchentoot)) > (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 5050)) > > (defun f () > (let ((username (hunchentoot:parameter "username"))) > (hunchentoot:start-session) > (setf (hunchentoot:session-value 'sessu) username) > (hunchentoot:session-value 'sessu))) > > (push (hunchentoot:create-prefix-dispatcher "/l" 'f) > hunchentoot:*dispatch-table*) > > (push (hunchentoot:create-static-file-dispatcher-and-handler "/" > "/Users/faruk/desktop/page.html") hunchentoot:*dispatch-table*) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josrr at ymail.com Thu Mar 20 22:36:35 2014 From: josrr at ymail.com (=?iso-8859-1?Q?Jos=E9_Ronquillo?=) Date: Thu, 20 Mar 2014 15:36:35 -0700 (PDT) Subject: yet another session problem In-Reply-To: <1395353535.51893.YahooMailNeo@web122906.mail.ne1.yahoo.com> References: <1395353383.82921.YahooMailNeo@web122901.mail.ne1.yahoo.com> <1395353535.51893.YahooMailNeo@web122906.mail.ne1.yahoo.com> Message-ID: <1395354995.93859.YahooMailNeo@web122903.mail.ne1.yahoo.com> Also, i don't understand why session-value does not return the saved string value but generates the "internal error", try this: (defun f () ? (let ((username (hunchentoot:parameter "username")) (session (or ?hunchentoot:*session* (hunchentoot:start-session)))) ? ? (if username (setf (hunchentoot:session-value 'sessu session) username)) ? ? (format 'nil "session:~a value:~a~%" ? ?session ? ?(hunchentoot:session-value 'sessu session)))) First send the username: http://127.0.0.1:5050/l?username=jose after that, get the saved session value http://127.0.0.1:5050/l -------------- next part -------------- An HTML attachment was scrubbed... URL: From farukscan at gmail.com Sun Mar 9 20:15:48 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Sun, 9 Mar 2014 22:15:48 +0200 Subject: serving html linked to css or js files Message-ID: maybe comic enough but i cannot serve an html file that is linked to css file. test.html asdf mystyle.css body { background-color:tan; } this html is rendered when i double click it. but i cannot serve it with style aded. alt console says: 127.0.0.1 - [2014-03-09 22:09:46] "GET /test HTTP/1.1" 200 114 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" 127.0.0.1 - [2014-03-09 22:09:46] "GET /~/mystyle.css HTTP/1.1" 404 360 " http://localhost:5050/test" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9" What should i do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Thu Mar 20 08:53:40 2014 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 20 Mar 2014 09:53:40 +0100 Subject: Another session problem In-Reply-To: References: <86y50546v1.fsf@math.fau.de> Message-ID: 2014-03-20 9:48 GMT+01:00 Edi Weitz : > On Thu, Mar 20, 2014 at 9:43 AM, Hans H?bner > wrote: > > I am not sure whether the functionality is working all that well > > It works fine. Here's an app that is used by my students almost every day: > > http://weitz.de/mars/ > > Click on the link above and look at the source code. You should see > that the
part is properly rewritten. > No offense intended - I just don?t use it, and I would avoid content rewriting in most circumstances. -Hans -------------- next part -------------- An HTML attachment was scrubbed... URL: From farukscan at gmail.com Sat Mar 15 17:42:46 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Sat, 15 Mar 2014 19:42:46 +0200 Subject: sessions In-Reply-To: References: Message-ID: morph composes home-page has changed (defun morph-columns1 () (html () (head () (link (list :rel "stylesheet" :href "reset.css")) (link (list :rel "stylesheet" :href "main.css")) (script () +js-sign-in+ +js-logout+ +jswritingdesk+ +jssavewriting+ +jsnotepad+)) (body () (morph-categories-axis) (morph-time-axis) (div (list :style "height: 45px; border: 1px solid;") (morph-name) (morph-search) (div (list :id "online-xor-offline" :style "height: 45px; border: 1px solid; float:left;") (if (signed-in-p);!!!t (div (list :id "if-online") (div (list :id "numbers-online" :style "border:1px solid; float:left;") "123 users online") (div (list :id "username" :style "border:1px solid; float:left;") (session-value '*username));!!!"sess val" (button (list :onclick "ajaxlogout()") "logout") (a (list :onclick "writingdesk()") "writing desk") (a (list :onclick "notepad()") "note pad") (a (list :onclick "published()") "published") (a (list :onclick "preferences()") "preferences")) (div (list :id "if-offline") (morph-sign-in-form) (morph-signup-link) ))))))) On Sat, Mar 15, 2014 at 7:40 PM, Faruk S. Can wrote: > my problem persists. once it has gone but i could not figure out how. > but now the problem is back. > any help? > > > On Wed, Mar 12, 2014 at 7:19 PM, Faruk S. Can wrote: > >> hi >> i cannot sustain a session. >> i login to my app. it shows my login name as i programmed. >> when i refresh the page it stays there. >> but when i refresh for the second time my session name and >> other things goes away and instead i see what is there for the >> not loginned case. >> >> I think i miss something in hunchentoot session hadling. >> >> ;all html generated by a macro: >> >> (defmacro ff (tag) >> `(defun ,tag (&rest c) >> (with-output-to-string (*standard-output*) >> (format t "<~a ~{~a='~a' ~}> ~{~a ~}" ',tag (car c) (cdr c) >> ',tag)))) >> >> ;;defining all tag functions: >> (progn >> (ff html) >> (ff title) >> (ff head) >> (ff meta) >> (ff link) >> (ff style) >> (ff script) >> (ff body) >> (ff span) >> (ff div) >> (ff section) >> (ff p) >> (ff form) >> (ff input) >> (ff button) >> (ff textarea) >> (ff a) >> (ff h1) >> (ff h2) >> (ff h3) >> (ff h4) >> (ff h5) >> (ff h6) >> (ff ol) >> (ff ul) >> (ff li)) >> >> ;authentication utilities used by the home page function at the bottom: >> >> (defun signed-in-p () >> (if (and (boundp '*session*) (session-value '*signed-in *session*)) >> t >> nil)) >> >> (defun signed-up-p (x y) >> (if (with-connection *conn1spec* >> (query (:select 'username 'password :from 'users.users >> :where (:and (:= 'username x) >> (:= 'password y))))) >> t >> nil)) >> >> (defun sign-in () >> (let ((username (parameter "username")) >> (password (parameter "password"))) >> (if (signed-up-p username password) >> (progn >> (start-session) >> (setf (session-value '*username) username) >> (setf (session-value '*signed-in) t) >> (morph-status-plate (session-value '*username))) >> (with-output-to-string (s) >> (princ (morph-sign-in-form) s) >> (princ "No record found!" s) >> (princ (a (list :href "/form-sign-up") "Sign up") s) >> )))) >> ;the data base querying functions are working correctly >> ;views generated: >> >> (defun morph-write-button () >> (div (list :style "border:1px solid; float:left;") >> (a (list :href "/writingp") "write"))) >> >> (defun morph-status-plate (username) >> (div (list :id "status-plate" :style "border:1px solid; float:left;") >> (span () "123 users online") >> (span () username) >> (button (list :onclick "ajaxlogout()") "logout"))) >> >> (defun morph-sign-in-form () >> (div (list :id "sign-in-form" :style "border:1px solid; float:left;") >> (form (list :method "" :action "") >> (input (list :id "username" :type "input" :name "username")) >> (input (list :id "password" :type "input" :name "password")) >> (input (list :onClick "ajaxsignin()" :type "button" :value >> "login"))))) >> >> ;at last >> ;the page i generate as home page: >> (div (list :id "sign-in-form-or-status-plate" >> :style "height: 45px; border: 1px solid; >> float:left;") >> (if (signed-in-p);;;;;; >> (with-output-to-string (s) >> (start-session) >> (princ (morph-status-plate (session-value >> '*username)) s) >> (princ (morph-write-button) s)) >> (with-output-to-string (s) >> (princ (morph-sign-in-form) s) >> (princ (a (list :href "form-sign-up") "Sign up") s)))) >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olegsivokon at gmail.com Sat Mar 1 20:58:55 2014 From: olegsivokon at gmail.com (Left Right) Date: Sat, 1 Mar 2014 22:58:55 +0200 Subject: hunchentoot serving manifest files, ie. .appcache files. In-Reply-To: References: Message-ID: Don't forget that sockets are concurrent by design: in a simplest scenario, you'd allocate a thread per connection. Not a very efficient way of dealing with it, but at least it is easy to implement in a way that you don't run into deadlocks or other errors caused by multiple threads accessing shared state. But if you choose to use server events, you would have to be very careful to write re-entrant functions to serve the request, which is particularly difficult because Hunchentoot relies on a handful of global variables to function... you may easily run yourself into a situation where two functions try to write to the same output stream, even at the level that Unicode byte sequences become interleaved and the receiving side would fail with arcane low-level decoding errors (happened to me before). On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret wrote: > Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is: > > var source=new EventSource(URL); > source.onmessage=function(event) { do_something_with(event.data); } > > and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form: > > data: [your data] > > to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.) > > rg > > On Feb 28, 2014, at 1:40 PM, Left Right wrote: > >> Not exactly answering your question, but if you are looking for push >> functionality in browser, then WebSockets might be a better option. >> The reason server-sent events exist is by and large due to the >> handicapped nature of most popular web-development stack in use today, >> such as PHP interpreter that has to be started on every connection by >> an HTTP server, such as Apache httpd or ngnx. This means that >> traditional setup works in a stateless manner. This is unlike, say, >> most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, >> Tornado), where the setup is normally stateful, meaning that you >> wouldn't need to restart the interpreter upon each request, instead, >> your server would persist the state until it is shut down. Hunchentoot >> belongs to the later category. >> >> Now, because it's not really possible to persist a PHP session across >> multiple requests, a technique first known as long polling appeared. >> The operating principle was that the server, in response to an HTTP >> request would not close the connection immediately, instead it would >> keep sending the information, whenever the application state at the >> server would demand it. The receiving side (the browser) would listen >> to updates on this connection and interpret them as "pushes". Event >> stream is a refinement of this scheme. >> >> WebSockets, on the other hand, are plain TCP sockets, which means that >> they don't require HTTP wrapping to function. I haven't had much >> experience with JavaScript WebSockets, but I used their analogy in >> Flash quite a bit. It was a relief not to depend on the bizarre rules >> of HTTP protocol and its encodings, headers and so on. So I would >> expect the same to hold for WebSockets. >> >> Best, >> >> Oleg >> >> On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can wrote: >>> I have read in w3schools about usage of server sent events in html5. >>> it says: >>> >>> Set the "Content-Type" header to "text/event-stream" >>> Specify that the page should not cache >>> Output the data to send (Always start with "data: ") >>> >>> that is in echo line in php code as echo "data: The server time is: >>> {$time}\n\n"; >>> >>> Flush the output data back to the web page >>> >>> http://www.w3schools.com/html/html5_serversentevents.asp >>> examples here are in php for server side. i am using hunchentoot on common >>> lisp. >>> >>> >>> >>> On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can wrote: >>>> >>>> I >>>> have another question about hunchentoot. Is it possible to use server >>>> sent events with hunchentoot, like other html5 improvements mentioned in >>>> w3schools-html5 such as app cache, local storage, session storage? as that >>>> one related to and depend on the server side support. >>>> >>> >> > From edi at agharta.de Thu Mar 20 11:01:49 2014 From: edi at agharta.de (Edi Weitz) Date: Thu, 20 Mar 2014 12:01:49 +0100 Subject: Another session problem In-Reply-To: <86siqd16tu.fsf@math.fau.de> References: <86y50546v1.fsf@math.fau.de> <86k3bp44ca.fsf@math.fau.de> <86siqd16tu.fsf@math.fau.de> Message-ID: On Thu, Mar 20, 2014 at 11:51 AM, Nicolas Neuss wrote: > ProxyRequests Off > ProxyPass /wissen http://localhost:8002 > ProxyPassReverse /wissen http://localhost:8002 I'd replace /wissen with /wissen/ and :8002 with :8002/ in both cases. That's what I do in my apps. (But then URLs ending in ".../wissen" won't work anymore if that's a problem for you. (Which you could in turn fix with mod_rewrite, hehe...)) Otherwise, as Hans already said, set *REWRITE-FOR-SESSION-URLS* to NIL if you don't need cookie-less sessions. That would be two possible sources for errors. (And, yes, Hunchentoot indeed adds the ACTION parameter. This behavior is controlled by url-rewrite:*url-rewrite-fill-tags* but you won't see it anymore if you set the variable mentioned above to NIL.) From farukscan at gmail.com Sat Mar 15 17:46:09 2014 From: farukscan at gmail.com (Faruk S. Can) Date: Sat, 15 Mar 2014 19:46:09 +0200 Subject: sessions In-Reply-To: References: Message-ID: Upon login it shows the value of (session-value *'username) on the top of the page as desired. And when I refresh the page it is still ok. But when page is doubled for the second time it is gone and the elements that is programmed to be shown when (signed-in-p) is nil is shown. On Sat, Mar 15, 2014 at 7:42 PM, Faruk S. Can wrote: > morph composes home-page has changed > (defun morph-columns1 () > (html () > (head () > (link (list :rel "stylesheet" :href "reset.css")) > (link (list :rel "stylesheet" :href "main.css")) > (script () +js-sign-in+ +js-logout+ +jswritingdesk+ > +jssavewriting+ +jsnotepad+)) > > (body () > > (morph-categories-axis) > (morph-time-axis) > (div (list :style "height: 45px; border: 1px solid;") > (morph-name) > (morph-search) > > (div (list :id "online-xor-offline" > :style "height: 45px; border: 1px solid; > float:left;") > (if (signed-in-p);!!!t > > (div (list :id "if-online") > (div (list :id "numbers-online" :style "border:1px > solid; float:left;") "123 users online") > (div (list :id "username" :style "border:1px solid; > float:left;") (session-value '*username));!!!"sess val" > (button (list :onclick "ajaxlogout()") "logout") > (a (list :onclick "writingdesk()") "writing desk") > (a (list :onclick "notepad()") "note pad") > (a (list :onclick "published()") "published") > (a (list :onclick "preferences()") "preferences")) > > (div (list :id "if-offline") > (morph-sign-in-form) > (morph-signup-link) > ))))))) > > > > On Sat, Mar 15, 2014 at 7:40 PM, Faruk S. Can wrote: > >> my problem persists. once it has gone but i could not figure out how. >> but now the problem is back. >> any help? >> >> >> On Wed, Mar 12, 2014 at 7:19 PM, Faruk S. Can wrote: >> >>> hi >>> i cannot sustain a session. >>> i login to my app. it shows my login name as i programmed. >>> when i refresh the page it stays there. >>> but when i refresh for the second time my session name and >>> other things goes away and instead i see what is there for the >>> not loginned case. >>> >>> I think i miss something in hunchentoot session hadling. >>> >>> ;all html generated by a macro: >>> >>> (defmacro ff (tag) >>> `(defun ,tag (&rest c) >>> (with-output-to-string (*standard-output*) >>> (format t "<~a ~{~a='~a' ~}> ~{~a ~}" ',tag (car c) (cdr c) >>> ',tag)))) >>> >>> ;;defining all tag functions: >>> (progn >>> (ff html) >>> (ff title) >>> (ff head) >>> (ff meta) >>> (ff link) >>> (ff style) >>> (ff script) >>> (ff body) >>> (ff span) >>> (ff div) >>> (ff section) >>> (ff p) >>> (ff form) >>> (ff input) >>> (ff button) >>> (ff textarea) >>> (ff a) >>> (ff h1) >>> (ff h2) >>> (ff h3) >>> (ff h4) >>> (ff h5) >>> (ff h6) >>> (ff ol) >>> (ff ul) >>> (ff li)) >>> >>> ;authentication utilities used by the home page function at the bottom: >>> >>> (defun signed-in-p () >>> (if (and (boundp '*session*) (session-value '*signed-in *session*)) >>> t >>> nil)) >>> >>> (defun signed-up-p (x y) >>> (if (with-connection *conn1spec* >>> (query (:select 'username 'password :from 'users.users >>> :where (:and (:= 'username x) >>> (:= 'password y))))) >>> t >>> nil)) >>> >>> (defun sign-in () >>> (let ((username (parameter "username")) >>> (password (parameter "password"))) >>> (if (signed-up-p username password) >>> (progn >>> (start-session) >>> (setf (session-value '*username) username) >>> (setf (session-value '*signed-in) t) >>> (morph-status-plate (session-value '*username))) >>> (with-output-to-string (s) >>> (princ (morph-sign-in-form) s) >>> (princ "No record found!" s) >>> (princ (a (list :href "/form-sign-up") "Sign up") s) >>> )))) >>> ;the data base querying functions are working correctly >>> ;views generated: >>> >>> (defun morph-write-button () >>> (div (list :style "border:1px solid; float:left;") >>> (a (list :href "/writingp") "write"))) >>> >>> (defun morph-status-plate (username) >>> (div (list :id "status-plate" :style "border:1px solid; float:left;") >>> (span () "123 users online") >>> (span () username) >>> (button (list :onclick "ajaxlogout()") "logout"))) >>> >>> (defun morph-sign-in-form () >>> (div (list :id "sign-in-form" :style "border:1px solid; float:left;") >>> (form (list :method "" :action "") >>> (input (list :id "username" :type "input" :name "username")) >>> (input (list :id "password" :type "input" :name "password")) >>> (input (list :onClick "ajaxsignin()" :type "button" :value >>> "login"))))) >>> >>> ;at last >>> ;the page i generate as home page: >>> (div (list :id "sign-in-form-or-status-plate" >>> :style "height: 45px; border: 1px solid; >>> float:left;") >>> (if (signed-in-p);;;;;; >>> (with-output-to-string (s) >>> (start-session) >>> (princ (morph-status-plate (session-value >>> '*username)) s) >>> (princ (morph-write-button) s)) >>> (with-output-to-string (s) >>> (princ (morph-sign-in-form) s) >>> (princ (a (list :href "form-sign-up") "Sign up") >>> s)))) >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: