- tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] Hunchentoot and threads
by Cyrus Harmon 20 Nov '08

20 Nov '08

I seem to recall that, a long time ago, TBNL/hunchentoot required threads. At some point Edi rigged up a singled threaded version but claimed that that was just for development/testing work and shouldn't be used in the real world. Now I understand that Hans has an aversion to threads as the multiplexing abstraction for webservers and that single threaded is "the one true way." I bring this up as background to me real problem, which is that, at least on FreeBSD, I seem to have a number of zombie threads that stick around after requests are made. Before I dig into the problem, I'd be curious to hear what folks' recommendations for running a low-traffic, but nevertheless hopefully reliable, site are. I had reasonably good luck with SBCL+threads and hunchentoot before the big rewrite, but since then, it has been reliable refusing to accept new connections after a week or two of use. Everything starts out fine and I can field some traffic and all is good: CL-USER> (sb-thread:list-all-threads) (#<SB-THREAD:THREAD "reader-thread" RUNNING {59B6B241}> #<SB-THREAD:THREAD "repl-thread" RUNNING {59B6B0F1}> #<SB-THREAD:THREAD "control-thread" RUNNING {59B60359}> #<SB-THREAD:THREAD "auto-flush-thread" RUNNING {59B601D9}> #<SB-THREAD:THREAD "initial thread" RUNNING {598D79B1}>) However, after some period, I see an accumulation of worker threads that won't die and eventually I'm unable to start a new thread to field the request. Who knows where the problem is... Could be in hunchentoot proper, in usocket, in SBCL's FreeBSD threads, etc... At the moment I don't have any debugging info on the problem, as all seems to be working ok since I restarted the web server a few minutes ago. The next time the problem crops up, I'll reply to this with some debugging information. This seems to be the one major "regression" from the old hunchentoot that has me considering going back to the stable release (although I've already ported my code forward for the new API, so I'd hate to have to do that). Better yet would be to either track down and fix the problem or to be convinced that this is just broken and is never going to work and figure out how to make my stuff work in a single threaded lisp. One more question regarding threads, is it possible to use a threaded lisp to act like the single threaded server does? That is to use threads, but to only have one thread doing the hard work, using serve- event for the multiplexing? My initialization code relies on setting some state after starting to listen for requests, so I can't just flip the switch to single-threaded mode and have everything work out of the box. Thanks for all of the hunchentoot rewrite efforts! On the whole it seems like a good thing, but fixing this issue would make me a much happier hunchentoot user. Cyrus

6 10

[hunchentoot-devel] Can we control the number of worker-threads/per-session?
by Matthew Lamari 13 Nov '08

13 Nov '08

(I'm on lispworks/win32) Aside from questions of the wisdom of controlling this. . . >From my observations, I've seen Hunchentoot limit the number of worker threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads. I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session? Thanks, Matt

6 11

[hunchentoot-devel] blinking hunchentoot logo
by Jeff Cunningham 10 Nov '08

10 Nov '08

My daughter was looking at the Hunchentoot logo this morning and said she thought someone ought to make it animated so that one the eyes blinks every so often, and then another one - randomly. I don't know how to do that. Does anyone know how to do that? It would be really cool. I suppose it would have to be a GIF though. Jeff

7 17

[hunchentoot-devel] Fwd: hunchentoot session hijacking
by Hans Hübner 27 Oct '08

27 Oct '08

Hi, forwarding an off-list discussion. Please review and comment to the list. Thanks, Hans ---------- Forwarded message ---------- From: Hans Hübner <hans(a)huebner.org> Date: Fri, Oct 24, 2008 at 12:54 Subject: Re: hunchentoot session hijacking To: Anton Vodonosov <avodonosov(a)yandex.ru> Cc: Edi Weitz <edi(a)agharta.de> Hi Anton, thank you for your security analysis. I agree that, even though the weakness of the session protection is documented, it would be better to provide for a secure scheme from the beginning. The problem at hand is that there is no portable secure solution. Adding a documented hook to Hunchentoot that allows for setting up a more secure scheme is certainly possible, but I think that this would not be beneficial: Such a hook is trivial, and the concerned user can always implement HUNCHENTOOT:RESET-SESSION-SECRET in a more secure fashion, overriding the default implementation. Another option would be to make specifying a part of the session secret mandatory at server startup time. I would find this inconvenient, in particular if it cannot be demonstrated that the scheme would be substantially more secure than the existing mechanism. Another option would be to provide for a portable secure implementation, but I certainly lack the time to look at this. So, if you feel that this is something that needs to be addressed, can you provide us with a patch, either to the source code or to the documentation? A documentation patch could consist of a short summary of your security analysis and a description how the concerned user can make the server more secure. Thanks, Hans On Thu, Oct 23, 2008 at 23:38, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > Hello. > > I've recently discovered that hunchentoot sessions are quite easy to > hijack (while I was investigating generation of unpredictable keys > for cl-openid). Therefore I want to suggest a solution to make them > more secure. > > I know the documentations discourages from considering sessions as > really secure, but after some experiments it turned out that in normal > case it is a matter of just several hours to hijack hunchentoot > sessions. > > For example, I know that the hunchentoot-session cookie value is > "2561%3A5767E844C4A3FBEDBCA79C349F1DE52B; path=/". > > 2561 here is SESSION-ID. 3A5767E844C4A3FBEDBCA79C349F1DE52B is value > produced by > (encode-session-string > (session-id session) > (session-user-agent session) > (session-remote-addr session) ;; usually ignored > (session-start session))) > > I know my SESSION-USER-AGENT. SESSION-START is most likely the > value of the Date header in the server response. > > The only unknown value is the *SESSION-SECRET* global used by > ENCODE-SESSION-STRING. But it is easy guessable. It is generated by a > series or RANDOM invocation. RANDOM implementation is usually deterministic, > and therefore *SESSION-SECRET* is fully determined initial value of > *THE-RANDOM-STATE*, which in turn is usually fully determined by current > time (i.e. server startup time). I.e. *SESSION-SECRET* is fully > determined by the server start time. > > For example in SBCL, MAKE-RANDOM-STATE uses GET-UNIVERSAL-TIME. > Resolution of GET-UNIVERSAL-TIME is one second i.e. if we want > to consider a year-long period, we have only (* 365 24 60 60) > == 31536000 values to consider. This took several hours of a > moderate laptop. > > After we know *SESSION-SECRET*, we may easy calculate session cookie > for any given session ID (we usually do not know session start > time of other people, but it is in the range of 30 minutes from current > time for active sessions). > > In short, to make session more secure we need unguessable > *SESSION-SECRET*. It is possible to use /dev/[u]random on Linux > and CryptoAPI on Windows, but the simplest way, in my opinion, > would be to provide a public function to set session secret (or a > part of session secret). User will set it to some passphrase. > > Best regards, > - Anton > > > > >

2 3

[hunchentoot-devel] Broken port-clisp.lisp under CLISP 2.44 [patch]
by Abhishek Reddy 16 Oct '08

16 Oct '08

Hello, Hunchentoot 0.15.7 fails to compile under CLISP 2.44 (GNU/Linux), with this message[1]. In port-clisp.lisp, there is a call to SYS::FRAME-UP-1. As of CLISP 2.44, this is an unavailable function name. It was replaced[2] by (SYS::FRAME-UP 1 ...). This issue has been addressed[3] in more recent swank-clisp.lisp versions. Below[4] is a patch adapted from there. It adds a symbol to *features* depending on CLISP's version, upon which it conditionally calls the right frame-up function. Cheers, Abhishek. [1] ;; Compiling file /home/abhishek/.clc/site/hunchentoot-0.15.7/port-clisp.lisp ... ** - Continuable Error INTERN("FRAME-UP-1"): #<PACKAGE SYSTEM> is locked If you continue (by typing 'continue'): Ignore the lock and proceed The following restarts are also available: RETRY :R1 Retry performing #<ASDF:COMPILE-OP NIL #x204E54BE> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x204DC7EE>. ACCEPT :R2 Continue, treating #<ASDF:COMPILE-OP NIL #x204E54BE> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x204DC7EE> as having been successful. ABORT :R3 Abort main loop [2] http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/src/ChangeLog?r1=1.5922… [3] http://github.com/pat-maddox/slime/commit/0ad4624b6f1d5c6bcfc773dcb2452dd4f… [4] diff -u port-clisp.lisp port-clisp.lisp.new --- port-clisp.lisp 2008-10-17 08:13:11.000000000 +1300 +++ port-clisp.lisp.new 2008-10-17 07:13:58.000000000 +1300 @@ -109,13 +109,19 @@ is a function frame." (char= #\< (aref formatted-frame 0))) +(eval-when (:compile-toplevel :load-toplevel :execute) + (when (string< "2.44" (lisp-implementation-version)) + (pushnew :clisp-2.44+ *features*))) + (defun get-backtrace (error) "This is the function that is used internally by Hunchentoot to show or log backtraces." (declare (ignore error)) (with-output-to-string (stream) (do ((last nil frame) - (frame (sys::the-frame) (sys::frame-up-1 frame 1))) + (frame (sys::the-frame) + #+clisp-2.44+ (sys::frame-up 1 frame 1) + #-clisp-2.44+ (sys::frame-up-1 frame 1))) ((eq frame last)) (let ((formatted-frame (format-frame frame))) (when (function-frame-p formatted-frame)

1 0

Re: [hunchentoot-devel] Troubles on OS X with Hunchentoot
by Bob Hutchison 10 Oct '08

10 Oct '08

I got a response to this problem on the lispworks mailing list. On 10-Oct-08, at 10:02 AM, Pascal Costanza wrote: > > Hi there, > > Yes, this is Leopard's weird security system. In the firewall > settings of your system, don't select "Set access for specific > services and applications", but only either "Allow all incoming > connections" or "Allow only essential services." > > Leopard stores firewall settings per application in the application > file itself when you select the wrong option here, and this destroys > the LispWorks image. > > > Pascal > > On 9 Oct 2008, at 23:14, Bob Hutchison wrote: > > -- > Lisp50: http://www.lisp50.org > > Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net > Vrije Universiteit Brussel, Programming Technology Lab > Pleinlaan 2, B-1050 Brussel, Belgium > > On 9-Oct-08, at 5:15 PM, Bob Hutchison wrote: > >> Hi, >> >> On occasion when I'm running Hunchentoot in LW 5.5.1 when I quit >> then restart LW I get the following error: >> >> Lisp executable xfasl-image.static apparently corrupted. >> (Truncated?) Cannot restart. >> >> I'm having to copy the LispWorks.app from a backup overtop the >> version in /Applications/... >> >> Any idea what might be causing this? >> >> I'll be asking on the LispWorks mailing list as well. >> >> Cheers, >> Bob >

1 0

[hunchentoot-devel] Why override the standard dispatcher?
by Bryan Emrys 22 Sep '08

22 Sep '08

Newbie question. Can anyone explain why people would want to override the standard dispatcher? E.g. in http://www.lispcast.com/files/episode3/reddit-lisp.lisp (defclass handler () ((url :initarg :url :accessor url :type string) (handler :initarg :handler :accessor handler) (name :initarg :name :accessor name :type symbol))) (defvar *handlers* (make-hash-table)) (defun our-handler (request) (let ((handler (gethandler (hunchentoot:script-name request)))) (when handler (handler handler)))) (setf hunchentoot:*dispatch-table* (list 'our-handler))

2 1

[hunchentoot-devel] Preventing users to upload too big files
by Andrei Stebakov 19 Sep '08

19 Sep '08

I wonder what's the best way to handle the case when a user tries to upload a very large file. Basically we need to stop execution before it gets to the parse-rfc2388-form-data and report the problem to the user. I can think of placing some function call inside request's constructor (defmethod initialize-instance :after ((request request) &rest init-args) Something like: (let* ((check (find-symbol "CHECK-FILE-SIZE" :your-package)) (header-value (find-symbol "HEADER-VALUE" :drakma)) (length (parse-integer (funcall header-value :content-length headers-in)))) (funcall check length)) Inside function check-file-size you would raise an error if the file is too big. The problem is that this error gets handled by the lisp debugger and I can't propagate it to the user. Another thing, it's a dirty hack, what's the better way of doing this? Thank you, Andrew

2 4

[hunchentoot-devel] Hunchentoot and raw data output
by public.avatar＠gmail.com 19 Sep '08

19 Sep '08

Hi! How can I output data without a headers? I try to use external CSS, but hunchentoot add a header to CSS data.

3 7

[hunchentoot-devel] thread safety in session-value
by Anton Vodonosov 04 Sep '08

04 Sep '08

Hello. Just noticed in the sources that SESSION-VALUE code does not have WITH-LOCK. IMHO it is necessary here. Best regards, -Anton

3 8