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

Basic authorization and colon in user, password
by Daniel Brunner 08 Apr '15

08 Apr '15

Hi to all, as I understood RFC2617 for basic authorization it is assumed that username and password are seperated with a colon ":". When a user enters an additional colon in username and/or password Hunchentoot (1.2.7) fails with an error: [2013-04-30 09:34:34 [ERROR]] Extra arguments in ("foo" "bar" "blafasel") don't match lambda list (&OPTIONAL HUNCHENTOOT::USER HUNCHENTOOT::PASSWORD). The code in question is in the function AUTHORIZATION in request.lisp: -- (destructuring-bind (&optional user password) (split ":" (base64:base64-string-to-string (subseq authorization start))) -- I would prefer if Hunchentoot could handle this case silently without signalling an error. What do you think? Kind regards, Daniel

3 4

yet another session problem
by Faruk S. Can 08 Apr '15

08 Apr '15

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*)

2 6

create-random-string revisited
by Sabra Crolleton 08 Apr '15

08 Apr '15

Quite awhile ago I proposed strengthening create-random-string with something that required cl-ssl as a dependency and it was correctly pointed out that some implementations do not play well with cl-ssl. Would using the strong-random function from ironclad be acceptable? E.g. (defun create-random-string (&optional (n 10) (base 16)) "Creates a random string using ironclad's strong-random function with base BASE and N digits" (setf crypto:*prng* (crypto:make-prng :fortuna)) (subseq (with-output-to-string (s) (loop for i to n do (format s "~VR" base (ironclad:strong-random 100000000000)))) 0 n)) Sabra

6 6

Using screen to put CCL/HT in production as a web server
by Ron Garret 08 Apr '15

08 Apr '15

I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this? This is one set of lessons I'd rather not learn the hard way. Thanks, rg

9 10

Session identity vanishing
by peter 08 Apr '15

08 Apr '15

Using Hunchentoot 1.2.7 on Clozure 1.9-r15808 I get cookies OK when serving HTML from any host I've tried. Serving JSON on Mac (DarwinX8664) works OK too. But I lose the cookie (session identity) when serving JSON on EC2 (linuxx8664). I expect the deficiency is in my code, but am foxed. Any suggestions?

1 0

Bug: *PRINT-BASE* affects radix of Content-Length header in reply
by Chaitanya Gupta 08 Apr '15

08 Apr '15

The radix used to print the value of the Content-Length header in reply is affected by the value set for *PRINT-BASE* in my SLIME REPL. This should not happen; Content-Length should always be in base 10 I believe. Here's a minimal test case: (hunchentoot:define-easy-handler (content-length-test :uri "/content-length-test") () "Foo Bar Baz") When *PRINT-BASE* is 10, $ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: 11 ...snipped... * Connection #0 to host localhost left intact Foo Bar Baz When *PRINT-BASE* is 16, $ curl -v http://localhost:4242/content-length-test * About to connect() to localhost port 4242 (#0) ...snipped... < HTTP/1.1 200 OK < Content-Length: B ...snipped... * Excess found in a non pipelined read: excess = 11 url = /content-length-test (zero-length body) * Connection #0 to host localhost left intact I am running Hunchentoot 1.2.19 on SBCL 1.1.4 on OS X Mountain Lion. Chaitanya

2 2

Cant serve static files
by Oleg Sivokon 08 Apr '15

08 Apr '15

Hello list, There should be something very simple I've overlooked, yet I can't find it. Hunchentoot seems not to be able to locate the root directory, where I have my static content, and I can't get it to print any useful information about it. That's why I'm asking for your help. Below is my setup: (setf (logical-pathname-translations "rgol") '(... ("WWW;*.*.*" "/home/wvxvw/.../www/") ("WWW;*;*.*.*" "/home/wvxvw/.../www/*") ...)) (make-instance 'hunchentoot:acceptor :port 4242 :document-root #p"rgol:www;" :message-log-destination #p"rgol:logs;messages.log" :access-log-destination #p"rgol:logs;access.log") I've defined another handler, which doesn't depend on static files, and it works fine, however, when I try to access static files, the log record looks like this: 127.0.0.1 - [2014-01-31 17:12:40] "GET /img/made-with-lisp-logo.jpg HTTP/1.1" 404 206 "http://localhost:4242/game.html" "Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0" But the file is definitely there, because if I try this in REPL: (directory #p"rgol:www;*.*") (#P"/home/wvxvw/.../www/game.html" ... more files ...) My version of Hunchentoot is: hunchentoot:*hunchentoot-version* "1.2.17" $ sbcl --version SBCL 1.1.2-1.fc18 Best, Oleg

3 8

have there been any advances in authentication, content negotiation, or structured response status generation?
by james anderson 08 Apr '15

08 Apr '15

good evening; neither a read through the pages on lists.common-lisp.net, nor a search through gmane's offering yielded anything substantive on facilities to be combined with hunchentoot for - authentication : alternatively basic, token, and session based? - content negotiation : resolving request headers against declared availability to yield effective content type, encoding, etc? - structured response status generation : condition handler -> response status control structures? when these operations cannot be delegated to a mediating server, is the common practice to code them form scratch? best regards, from berlin,

3 2

Persistent sessions
by Ron Garret 08 Apr '15

08 Apr '15

I need to be able to save and restore HT sessions so that they will survive a server restart. Before I dive into this I thought I would ask if anyone has done this already so I don’t reinvent the wheel. Thanks, rg

4 7

Re: Session identity vanishing
by Edi Weitz 08 Apr '15

08 Apr '15

It was just a guess. Probably won't happen with JSON, but I've seen plug-ins sending their own user agent strings. Maybe in your case it's a timing issue? Seems you'll have to debug it the hard way. On Sun, Oct 27, 2013 at 9:10 PM, peter <p2.edoc(a)gmail.com> wrote: > *use-user-agent-for-sessions* is T > > (so a session will cease to be accessible > if the client sends a different 'User-Agent' header) > > But why should the user-agent change because we're dealing with a JSON > rather than HTML return? I'm dealing with the same session, same browser, > etc as far as the client end is concerned (ie. two successive clicks in the > same web page). > > Many thanks. > > > > At 6:47 PM +0100 13/10/27, Edi Weitz wrote: >> >> Did you try to set *use-remote-addr-for-sessions* and/or >> *use-user-agent-for-sessions* to NIL? >> >> Cheers, >> Edi. >> >> On Sun, Oct 27, 2013 at 5:44 PM, peter <p2.edoc(a)gmail.com> wrote: >>> >>> Using Hunchentoot 1.2.7 on Clozure 1.9-r15808 >>> I get cookies OK when serving HTML from any host I've tried. >>> Serving JSON on Mac (DarwinX8664) works OK too. >>> But I lose the cookie (session identity) when serving JSON on EC2 >>> (linuxx8664). >>> I expect the deficiency is in my code, but am foxed. >>> Any suggestions? >>> >

1 0