Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it?
On Fri, 04 Jan 2008 20:38:31 +0100, Andrea Chiumenti wrote:
Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it? Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it? <br>
If I understand you correctly, I think the only way to do this is to keep user sessions in an out-of-process server like a database.
Thanks, yes you understood me correctly.
On Jan 4, 2008 8:43 PM, Sohail Somani sohail@taggedtype.net wrote:
On Fri, 04 Jan 2008 20:38:31 +0100, Andrea Chiumenti wrote:
Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it? Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it? <br>
If I understand you correctly, I think the only way to do this is to keep user sessions in an out-of-process server like a database.
-- Sohail Somani http://uint32t.blogspot.com
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I'm not so sure actually. If you are running the multiple servers in the same Lisp instance and you have a list of the servers, you should be able to move sessions between them. Not sure how but... I still think it is simpler to use a database.
On Fri, 04 Jan 2008 20:47:42 +0100, Andrea Chiumenti wrote:
Thanks, yes you understood me correctly.
On Jan 4, 2008 8:43 PM, Sohail Somani sohail@taggedtype.net wrote:
On Fri, 04 Jan 2008 20:38:31 +0100, Andrea Chiumenti wrote:
Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it? Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it? <br>
If I understand you correctly, I think the only way to do this is to keep user sessions in an out-of-process server like a database.
Why do you need to mix in one session http and https?
Browsers do not support it. For example IE gives nasty popup warning every time you mix plain and ssl html in one page.
So why bother? Make ALL user sessions SSL, and leave plain http only for public part of web site.
_____
From: tbnl-devel-bounces@common-lisp.net [mailto:tbnl-devel-bounces@common-lisp.net] On Behalf Of Andrea Chiumenti Sent: Friday, January 04, 2008 11:48 AM To: General interest list for Hunchentoot and CL-WEBDAV Subject: Re: [hunchentoot-devel] session shearing question
Thanks, yes you understood me correctly.
On Jan 4, 2008 8:43 PM, Sohail Somani sohail@taggedtype.net wrote:
On Fri, 04 Jan 2008 20:38:31 +0100, Andrea Chiumenti wrote:
Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it?
Now that I've been able to start hunchentoot in ssl mode, if I start
another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is
there a possibility to do it? <br>
If I understand you correctly, I think the only way to do this is to keep user sessions in an out-of-process server like a database.
-- Sohail Somani http://uint32t.blogspot.com
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Suppose you have a web application: When a user accesses it, the application will create a session for this user (not already logged). Now suppose he will do something that need to be stored into session, as for example filling a chart in an e-commerce application. Now he needs to checkout his chart, but he must login into this e-commerce site/application, so he will be redirected to an encrypted connection, but the session, holding the chart, must not be loosen. This makes me think that I have to share a session (object/service) between a pair of hunchentoot instances.
On Jan 4, 2008 8:52 PM, Vagif Verdi vagif@cox.net wrote:
Why do you need to mix in one session http and https?
Browsers do not support it. For example IE gives nasty popup warning every time you mix plain and ssl html in one page.
So why bother? Make ALL user sessions SSL, and leave plain http only for public part of web site.
*From:* tbnl-devel-bounces@common-lisp.net [mailto: tbnl-devel-bounces@common-lisp.net] *On Behalf Of *Andrea Chiumenti *Sent:* Friday, January 04, 2008 11:48 AM *To:* General interest list for Hunchentoot and CL-WEBDAV *Subject:* Re: [hunchentoot-devel] session shearing question
Thanks, yes you understood me correctly.
On Jan 4, 2008 8:43 PM, Sohail Somani sohail@taggedtype.net wrote:
On Fri, 04 Jan 2008 20:38:31 +0100, Andrea Chiumenti wrote:
Now that I've been able to start hunchentoot in ssl mode, if I start another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is there a possibility to do it?
Now that I've been able to start hunchentoot in ssl mode, if I start
another hunchentoot instance handling normal http requests, does hunchentoot shares user session between the two instances,if not is
there a possibility to do it? <br>
If I understand you correctly, I think the only way to do this is to keep user sessions in an out-of-process server like a database.
-- Sohail Somani http://uint32t.blogspot.com
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
"Andrea Chiumenti" kiuma72@gmail.com writes:
Suppose you have a web application: When a user accesses it, the application will create a session for this user (not already logged). Now suppose he will do something that need to be stored into session, as for example filling a chart in an e-commerce application. Now he needs to checkout his chart, but he must login into this e-commerce site/application, so he will be redirected to an encrypted connection, but the session, holding the chart, must not be loosen. This makes me think that I have to share a session (object/service) between a pair of hunchentoot instances.
Then, as Sohail mentioned previously, you will need an intermediate layer for storing temporary client data in an accesible state by both instances. While you may achieve this by using a database server, it might be more convenient and easy to use some sort of persistance layer. (See cl-perec[1] and elephant[2] projects.)
[1] http://common-lisp.net/project/cl-perec/ [2] http://common-lisp.net/project/elephant/
Regards.
to have a process safe server, both cl-perec and elephant use a non pure lisp solution :(
On Jan 4, 2008 10:32 PM, Volkan YAZICI yazicivo@ttmail.com wrote:
"Andrea Chiumenti" kiuma72@gmail.com writes:
Suppose you have a web application: When a user accesses it, the application will create a session for this user (not already logged). Now suppose he will do something that need to be stored into session, as for example filling a chart in an e-commerce application. Now he needs to checkout his chart, but he must login into this e-commerce site/application, so he will be redirected to an encrypted connection, but the session, holding the chart, must not be loosen. This makes me think that I have to share a session (object/service) between a pair of hunchentoot instances.
Then, as Sohail mentioned previously, you will need an intermediate layer for storing temporary client data in an accesible state by both instances. While you may achieve this by using a database server, it might be more convenient and easy to use some sort of persistance layer. (See cl-perec[1] and elephant[2] projects.)
[1] http://common-lisp.net/project/cl-perec/ [2] http://common-lisp.net/project/elephant/
Regards. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
"Andrea Chiumenti" kiuma72@gmail.com writes:
to have a process safe server, both cl-perec and elephant use a non pure lisp solution :(
So you shouldn't be using HTTPS with hunchentoot too, 'cause it depends on a foreign ssl library. That's the trade. But you may want to chose waiting for somebody to implement an ACID compliant storage framework in lisp -- with tons of other indexing, concurrency, data integrity stuff. (By the way, there exists commercial solutions. See AllegroCache for instance.)
On the other hand, IIRC elephant could use Berkeley DB as a backend. AFAICS, probability of finding libdb installed on a system is much more higher than finding libssl installed.
Regards.
Ok, you convinced me. For now I can use elephant for my cl-webobjects project. Then I could hack swarmcache (http://swarmcache.sourceforge.net/) and port it to lisp (if I gain a bit more experience in CL coding)
On Jan 4, 2008 11:27 PM, Volkan YAZICI yazicivo@ttmail.com wrote:
"Andrea Chiumenti" kiuma72@gmail.com writes:
to have a process safe server, both cl-perec and elephant use a non pure lisp solution :(
So you shouldn't be using HTTPS with hunchentoot too, 'cause it depends on a foreign ssl library. That's the trade. But you may want to chose waiting for somebody to implement an ACID compliant storage framework in lisp -- with tons of other indexing, concurrency, data integrity stuff. (By the way, there exists commercial solutions. See AllegroCache for instance.)
On the other hand, IIRC elephant could use Berkeley DB as a backend. AFAICS, probability of finding libdb installed on a system is much more higher than finding libssl installed.
Regards. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hello, this morning, when I woke up, taken from curiosity, I've opened hunchentoot code to inspect how sessions are handled. I've seen that session modifiers are all protected with the WITH-LOCK form, now my question is *session-data* common to all hunchentoot servers instantiated on the same lisp instance ?
Another question, now suppose we have in a single hunchentoot server serves two applications ( distinguished by their path ). It seems that hunchentoot shares the session between these two, and sometime it's good, but what should I do if I want applications to share different sessions ?
On Jan 5, 2008 12:01 AM, Andrea Chiumenti kiuma72@gmail.com wrote:
Ok, you convinced me. For now I can use elephant for my cl-webobjects project. Then I could hack swarmcache (http://swarmcache.sourceforge.net/) and port it to lisp (if I gain a bit more experience in CL coding)
On Jan 4, 2008 11:27 PM, Volkan YAZICI yazicivo@ttmail.com wrote:
"Andrea Chiumenti" kiuma72@gmail.com writes:
to have a process safe server, both cl-perec and elephant use a non pure lisp solution :(
So you shouldn't be using HTTPS with hunchentoot too, 'cause it depends on a foreign ssl library. That's the trade. But you may want to chose waiting for somebody to implement an ACID compliant storage framework in lisp -- with tons of other indexing, concurrency, data integrity stuff. (By the way, there exists commercial solutions. See AllegroCache for instance.)
On the other hand, IIRC elephant could use Berkeley DB as a backend. AFAICS, probability of finding libdb installed on a system is much more higher than finding libssl installed.
Regards. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Sat, 5 Jan 2008 11:31:06 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
now my question is *session-data* common to all hunchentoot servers instantiated on the same lisp instance ?
Yes, it's a global special variable.
Another question, now suppose we have in a single hunchentoot server serves two applications ( distinguished by their path ). It seems that hunchentoot shares the session between these two, and sometime it's good, but what should I do if I want applications to share different sessions ?
There's currently no mechanism for this. Unless you write your own, of course.
Hello, Edi
I've spent the weekend on figuring out how to bind sessions for each application registered and finally I've found a solution! Before writing function redefinitions into my project, thing that I find a bit 'dirty', do you want me to post here my modifications so that sessions have their own realm and session cookies are bound to specific applications ?
Cheers, kiuma
On Jan 7, 2008 5:45 AM, Edi Weitz edi@agharta.de wrote:
On Sat, 5 Jan 2008 11:31:06 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
now my question is *session-data* common to all hunchentoot servers instantiated on the same lisp instance ?
Yes, it's a global special variable.
Another question, now suppose we have in a single hunchentoot server serves two applications ( distinguished by their path ). It seems that hunchentoot shares the session between these two, and sometime it's good, but what should I do if I want applications to share different sessions ?
There's currently no mechanism for this. Unless you write your own, of course. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi Edi, are you interested in these modifications ?
(defgeneric request-realm (req) (:documentation "Returns the realm under which the request has been sent. A realm is used to group resources under a common 'place', and is used for registered web applications to have different or common sessions for a give user.")) (defgeneric (setf request-realm) (value req) (:documentation "Sets the realm under which the request has been sent, where value is the realm name. A realm is used to group resources under a common 'place', and is used for registered web applications to have different or common sessions for a give user."))
(defmethod request-realm ((req hunchentoot::request)) (aux-request-value 'realm req))
(defmethod (setf request-realm) (value (req hunchentoot::request)) (setf (aux-request-value req) value))
(defclass session () ((session-id :initform (get-next-session-id) :reader session-id :type integer :documentation "The unique ID (an INTEGER) of the session.") (session-realm :initform (request-realm *request*) :reader session-realm :documentation "Defines a realm for this session. A realm is injected by *request* aux parameter, and is used to group resources that will share this session object.") (session-string :reader session-string :documentation "The session strings encodes enough data to safely retrieve this session. It is sent to the browser as a cookie value or as a GET parameter.") (user-agent :initform (user-agent *request*) :reader session-user-agent :documentation "The incoming 'User-Agent' header that was sent when this session was created.") (remote-addr :initform (real-remote-addr *request*) :reader session-remote-addr :documentation "The remote IP address of the client when this sessions was started as returned by REAL-REMOTE-ADDR.") (session-start :initform (get-universal-time) :reader session-start :documentation "The time this session was started.") (last-click :initform (get-universal-time) :reader session-last-click :documentation "The last time this session was used.") (session-data :initarg :session-data :initform nil :reader session-data :documentation "Data associated with this session - see SESSION-VALUE.") (session-counter :initform 0 :reader session-counter :documentation "The number of times this session has been used.") (max-time :initarg :max-time :initform *session-max-time* :accessor session-max-time :type fixnum :documentation "The time (in seconds) after which this session expires if it's not used.")) (:documentation "SESSION objects are automatically maintained by Hunchentoot. They should not be created explicitly with MAKE-INSTANCE but implicitly with START-SESSION. Note that SESSION objects can only be created when the special variable *REQUEST* is bound to a REQUEST object."))
(defun encode-session-string (id user-agent remote-addr start realm) "Create a uniquely encoded session string based on the values ID, USER-AGENT, REMOTE-ADDR, and START" ;; *SESSION-SECRET* is used twice due to known theoretical ;; vulnerabilities of MD5 encoding (md5-hex (concatenate 'string *session-secret* (md5-hex (format nil "~A~A~@[~A~]~@[~A~]~A~@[~A~]" *session-secret* id (and *use-user-agent-for-sessions* user-agent) (and *use-remote-addr-for-sessions* remote-addr) start realm)))))
(defun stringify-session (session) "Creates a string representing the SESSION object SESSION. See ENCODE-SESSION-STRING." (encode-session-string (session-id session) (session-user-agent session) (session-remote-addr session) (session-start session) (session-realm session))
(defun session-verify (request) "Tries to get a session identifier from the cookies (or alternatively from the GET parameters) sent by the client. This identifier is then checked for validity against the REQUEST object REQUEST. On success the corresponding session object (if not too old) is returned (and updated). Otherwise NIL is returned." (let ((session-identifier (or (cookie-in *session-cookie-name* request) (get-parameter *session-cookie-name* request)))) (unless (and session-identifier (stringp session-identifier) (plusp (length session-identifier))) (return-from session-verify nil)) (destructuring-bind (id-string session-string) (split ":" session-identifier :limit 2) (let* ((id (and (scan "^\d+$" id-string) (parse-integer id-string :junk-allowed t))) (session (and id (get-stored-session id))) (user-agent (user-agent request)) (remote-addr (remote-addr request))) (unless (and session session-string (string= session-string (session-string session)) (string= session-string (encode-session-string id user-agent (real-remote-addr request) (session-start session) (request-realm request)))) (when *reply* (cond ((null session) (log-message :notice "No session for session identifier '~A' (User-Agent: '~A', IP: '~A')" session-identifier user-agent remote-addr)) (t (log-message :warning "Fake session identifier '~A' (User-Agent: '~A', IP: '~A')" session-identifier user-agent remote-addr)))) (when session (remove-session session)) (return-from session-verify nil)) (incf (slot-value session 'session-counter)) (setf (slot-value session 'last-click) (get-universal-time)) session))))
(defun start-session (&optional (path "/")) "Returns the current SESSION object. If there is no current session, creates one and updates the corresponding data structures. In this case the function will also send a session cookie to the browser. This function slightly differs from standard hunchentoot implementation because it can bound a session to a specific url inside the same server instance." (count-session-usage) (let ((session (session *request*))) (when session (return-from start-session session)) (setf session (make-instance 'session) (session *request*) session) (with-lock (*session-data-lock*) (setq *session-data* (acons (session-id session) session *session-data*))) (set-cookie *session-cookie-name* :value (session-cookie-value session) :path path) (setq *session* session)))
On Jan 7, 2008 7:43 AM, Andrea Chiumenti kiuma72@gmail.com wrote:
Hello, Edi
I've spent the weekend on figuring out how to bind sessions for each application registered and finally I've found a solution! Before writing function redefinitions into my project, thing that I find a bit 'dirty', do you want me to post here my modifications so that sessions have their own realm and session cookies are bound to specific applications ?
Cheers, kiuma
On Jan 7, 2008 5:45 AM, Edi Weitz < edi@agharta.de> wrote:
On Sat, 5 Jan 2008 11:31:06 +0100, "Andrea Chiumenti" < kiuma72@gmail.com> wrote:
now my question is *session-data* common to all hunchentoot servers instantiated on the same lisp instance ?
Yes, it's a global special variable.
Another question, now suppose we have in a single hunchentoot server serves two applications ( distinguished by their path ). It seems that hunchentoot shares the session between these two, and sometime it's good, but what should I do if I want applications to share different sessions ?
There's currently no mechanism for this. Unless you write your own, of course. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
sorry a missing paren in stringify-session
On Jan 8, 2008 10:12 AM, Andrea Chiumenti kiuma72@gmail.com wrote:
Hi Edi, are you interested in these modifications ?
(defgeneric request-realm (req) (:documentation "Returns the realm under which the request has been sent. A realm is used to group resources under a common 'place', and is used for registered web applications to have different or common sessions for a give user.")) (defgeneric (setf request-realm) (value req) (:documentation "Sets the realm under which the request has been sent, where value is the realm name. A realm is used to group resources under a common 'place', and is used for registered web applications to have different or common sessions for a give user."))
(defmethod request-realm ((req hunchentoot::request)) (aux-request-value 'realm req))
(defmethod (setf request-realm) (value (req hunchentoot::request)) (setf (aux-request-value req) value))
(defclass session () ((session-id :initform (get-next-session-id) :reader session-id :type integer :documentation "The unique ID (an INTEGER) of the session.") (session-realm :initform (request-realm *request*) :reader session-realm :documentation "Defines a realm for this session. A realm is injected by *request* aux parameter, and is used to group resources that will share this session object.") (session-string :reader session-string :documentation "The session strings encodes enough data to safely retrieve this session. It is sent to the browser as a cookie value or as a GET parameter.") (user-agent :initform (user-agent *request*) :reader session-user-agent :documentation "The incoming 'User-Agent' header that was sent when this session was created.") (remote-addr :initform (real-remote-addr *request*) :reader session-remote-addr :documentation "The remote IP address of the client when this sessions was started as returned by REAL-REMOTE-ADDR.") (session-start :initform (get-universal-time) :reader session-start :documentation "The time this session was started.") (last-click :initform (get-universal-time) :reader session-last-click :documentation "The last time this session was used.") (session-data :initarg :session-data :initform nil :reader session-data :documentation "Data associated with this session - see SESSION-VALUE.") (session-counter :initform 0 :reader session-counter :documentation "The number of times this session has been used.") (max-time :initarg :max-time :initform *session-max-time* :accessor session-max-time :type fixnum :documentation "The time (in seconds) after which this session expires if it's not used.")) (:documentation "SESSION objects are automatically maintained by Hunchentoot. They should not be created explicitly with MAKE-INSTANCE but implicitly with START-SESSION. Note that SESSION objects can only be created when the special variable *REQUEST* is bound to a REQUEST object."))
(defun encode-session-string (id user-agent remote-addr start realm) "Create a uniquely encoded session string based on the values ID, USER-AGENT, REMOTE-ADDR, and START" ;; *SESSION-SECRET* is used twice due to known theoretical ;; vulnerabilities of MD5 encoding (md5-hex (concatenate 'string *session-secret* (md5-hex (format nil "~A~A~@[~A~]~@[~A~]~A~@[~A~]" *session-secret* id (and *use-user-agent-for-sessions* user-agent) (and *use-remote-addr-for-sessions* remote-addr) start realm)))))
(defun stringify-session (session) "Creates a string representing the SESSION object SESSION. See ENCODE-SESSION-STRING." (encode-session-string (session-id session) (session-user-agent session) (session-remote-addr session) (session-start session) (session-realm session))
(defun session-verify (request) "Tries to get a session identifier from the cookies (or alternatively from the GET parameters) sent by the client. This identifier is then checked for validity against the REQUEST object REQUEST. On success the corresponding session object (if not too old) is returned (and updated). Otherwise NIL is returned." (let ((session-identifier (or (cookie-in *session-cookie-name* request) (get-parameter *session-cookie-name* request)))) (unless (and session-identifier (stringp session-identifier) (plusp (length session-identifier))) (return-from session-verify nil)) (destructuring-bind (id-string session-string) (split ":" session-identifier :limit 2) (let* ((id (and (scan "^\d+$" id-string) (parse-integer id-string :junk-allowed t))) (session (and id (get-stored-session id))) (user-agent (user-agent request)) (remote-addr (remote-addr request))) (unless (and session session-string (string= session-string (session-string session)) (string= session-string (encode-session-string id user-agent (real-remote-addr request) (session-start session) (request-realm request)))) (when *reply* (cond ((null session) (log-message :notice "No session for session identifier '~A' (User-Agent: '~A', IP: '~A')" session-identifier user-agent remote-addr)) (t (log-message :warning "Fake session identifier '~A' (User-Agent: '~A', IP: '~A')" session-identifier user-agent remote-addr)))) (when session (remove-session session)) (return-from session-verify nil)) (incf (slot-value session 'session-counter)) (setf (slot-value session 'last-click) (get-universal-time)) session))))
(defun start-session (&optional (path "/")) "Returns the current SESSION object. If there is no current session, creates one and updates the corresponding data structures. In this case the function will also send a session cookie to the browser. This function slightly differs from standard hunchentoot implementation because it can bound a session to a specific url inside the same server instance." (count-session-usage) (let ((session (session *request*))) (when session (return-from start-session session)) (setf session (make-instance 'session) (session *request*) session) (with-lock (*session-data-lock*) (setq *session-data* (acons (session-id session) session *session-data*))) (set-cookie *session-cookie-name* :value (session-cookie-value session) :path path) (setq *session* session)))
On Jan 7, 2008 7:43 AM, Andrea Chiumenti < kiuma72@gmail.com> wrote:
Hello, Edi
I've spent the weekend on figuring out how to bind sessions for each application registered and finally I've found a solution! Before writing function redefinitions into my project, thing that I find a bit 'dirty', do you want me to post here my modifications so that sessions have their own realm and session cookies are bound to specific applications ?
Cheers, kiuma
On Jan 7, 2008 5:45 AM, Edi Weitz < edi@agharta.de> wrote:
On Sat, 5 Jan 2008 11:31:06 +0100, "Andrea Chiumenti" < kiuma72@gmail.com> wrote:
now my question is *session-data* common to all hunchentoot servers instantiated on the same lisp instance ?
Yes, it's a global special variable.
Another question, now suppose we have in a single hunchentoot server serves two applications ( distinguished by their path ). It seems that hunchentoot shares the session between these two, and sometime it's good, but what should I do if I want applications to share different sessions ?
There's currently no mechanism for this. Unless you write your own, of course. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, 8 Jan 2008 10:12:50 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
are you interested in these modifications ?
Have you checked if it still works if you turn cookies off in your browser? Also, from a quick glance at the code I gather that the default request realm is NIL. Is that right? Does that work?
should be, give me one or two days, till I'll prepare a fully working example of cl-webobjects (hunchentoot based application container),that mekes use of realms.
On Jan 8, 2008 4:28 PM, Edi Weitz edi@agharta.de wrote:
On Tue, 8 Jan 2008 10:12:50 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
are you interested in these modifications ?
Have you checked if it still works if you turn cookies off in your browser? Also, from a quick glance at the code I gather that the default request realm is NIL. Is that right? Does that work? _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hello Edi, here it is a working example.
unpack the attached file and link the two asd files to your system.
call (asdf:oos 'asdf:load-op :cl-webobjects-test)
(in-package :cl-webobjects-test)
and then (startme)
in your browser go to http://localhost:4242/clwo/test/index.html
To verify the realm implementation click on the two realm tests.
I've no idea on how to do with cookies disabled, because I'm relatively new to Hunchentoot
What I've modified for hunchentoot is locates in file src/hunchentoot- overrides.lisp
Let me know, ciao
kiuma
On Jan 8, 2008 6:06 PM, Andrea Chiumenti kiuma72@gmail.com wrote:
should be, give me one or two days, till I'll prepare a fully working example of cl-webobjects (hunchentoot based application container),that mekes use of realms.
On Jan 8, 2008 4:28 PM, Edi Weitz < edi@agharta.de> wrote:
On Tue, 8 Jan 2008 10:12:50 +0100, "Andrea Chiumenti" < kiuma72@gmail.com> wrote:
are you interested in these modifications ?
Have you checked if it still works if you turn cookies off in your browser? Also, from a quick glance at the code I gather that the default request realm is NIL. Is that right? Does that work? _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, 9 Jan 2008 11:27:21 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
I've no idea on how to do with cookies disabled, because I'm relatively new to Hunchentoot
Well, as I already said, I currently don't have the time to do this, and I don't think it's a very important feature. So, you'll either have to send a complete and fully-tested patch that's backwards-compatible or you'll have to wait until I get around to do it myself.
Cheers, Edi.
Edi, As a Murphi Law confirmation, session handling with session encoded into request doesn't work :/, I'm working on it. Modifications are of course backward compatible!
The importance on separate sessions depends only on how a person want to use hunchentoot, it has sense only if someone want to use hunchentoot as an application server so having sessions bound do 'deployed' applications.
I'll make the realm patch work very soon, cu,
kiuma
On Jan 14, 2008 8:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, 9 Jan 2008 11:27:21 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
I've no idea on how to do with cookies disabled, because I'm relatively new to Hunchentoot
Well, as I already said, I currently don't have the time to do this, and I don't think it's a very important feature. So, you'll either have to send a complete and fully-tested patch that's backwards-compatible or you'll have to wait until I get around to do it myself.
Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Edi, I've been able to make it work with url-rewriting, but I don't know how rewriting should behave when referencing other realms. options are 1) append the sessionid for realm1 even to realm2 related resources (not very correct). 2) append nothing if resources belong to realm 2. (correct and easy), but when navigate from realm1 to realm2 you'll loose the session if cookies are disabled. 3) handle a sort of parent session that holds all sessions in realms, and then handle the url rewriting... (this requires more work)
kiuma
On Jan 14, 2008 1:24 PM, Andrea Chiumenti kiuma72@gmail.com wrote:
Edi, As a Murphi Law confirmation, session handling with session encoded into request doesn't work :/, I'm working on it. Modifications are of course backward compatible!
The importance on separate sessions depends only on how a person want to use hunchentoot, it has sense only if someone want to use hunchentoot as an application server so having sessions bound do 'deployed' applications.
I'll make the realm patch work very soon, cu,
kiuma
On Jan 14, 2008 8:52 AM, Edi Weitz <edi@agharta.de > wrote:
On Wed, 9 Jan 2008 11:27:21 +0100, "Andrea Chiumenti" < kiuma72@gmail.com> wrote:
I've no idea on how to do with cookies disabled, because I'm relatively new to Hunchentoot
Well, as I already said, I currently don't have the time to do this, and I don't think it's a very important feature. So, you'll either have to send a complete and fully-tested patch that's backwards-compatible or you'll have to wait until I get around to do it myself.
Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Option 4) if no session cookie handling, then realm is ignored (maybe this is the most correct)
On Jan 14, 2008 3:33 PM, Andrea Chiumenti kiuma72@gmail.com wrote:
Edi, I've been able to make it work with url-rewriting, but I don't know how rewriting should behave when referencing other realms. options are
- append the sessionid for realm1 even to realm2 related resources (not
very correct). 2) append nothing if resources belong to realm 2. (correct and easy), but when navigate from realm1 to realm2 you'll loose the session if cookies are disabled. 3) handle a sort of parent session that holds all sessions in realms, and then handle the url rewriting... (this requires more work)
kiuma
On Jan 14, 2008 1:24 PM, Andrea Chiumenti kiuma72@gmail.com wrote:
Edi, As a Murphi Law confirmation, session handling with session encoded into request doesn't work :/, I'm working on it. Modifications are of course backward compatible!
The importance on separate sessions depends only on how a person want to use hunchentoot, it has sense only if someone want to use hunchentoot as an application server so having sessions bound do 'deployed' applications.
I'll make the realm patch work very soon, cu,
kiuma
On Jan 14, 2008 8:52 AM, Edi Weitz < edi@agharta.de > wrote:
On Wed, 9 Jan 2008 11:27:21 +0100, "Andrea Chiumenti" < kiuma72@gmail.com> wrote:
I've no idea on how to do with cookies disabled, because I'm relatively new to Hunchentoot
Well, as I already said, I currently don't have the time to do this, and I don't think it's a very important feature. So, you'll either have to send a complete and fully-tested patch that's backwards-compatible or you'll have to wait until I get around to do it myself.
Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hello, finally I've been able to make session sharing (the realm thing) to work both when cookies are enabled and when they are disabled with url-rewriting.
The behavior in url-rewriting is that, when switching from realm1 to realm2 the session is reset in realm2: this means (setf *session* nil) and (setf (session request) nil).
So this will make to create a new session for realm2 but it will maintain the session for realm1. Navigating inside the same realm maintains the session.
I need the realm behavior for my project (renamed to claw Common Lisp Action Web) that hopefully will be soon delivered on common-lisp.net
The actual samples are built against claw, that uses the modified(patched) version of hunchentoot v.0.15.0 .
I can add samples in hunchentoot test file too, and send the patched version (is there a svn/cvs version around?), or if you prefer I can give the huncentoot-overrides.lisp file that contains modifications.
Please let me know, because I need these info to proceed with my project.
Have a nice day, Andrea Chiumenti
On Jan 14, 2008 4:10 PM, Andrea Chiumenti kiuma72@gmail.com wrote:
Option 4) if no session cookie handling, then realm is ignored (maybe this is the most correct)
On Jan 14, 2008 3:33 PM, Andrea Chiumenti <kiuma72@gmail.com > wrote:
Edi, I've been able to make it work with url-rewriting, but I don't know how rewriting should behave when referencing other realms. options are
- append the sessionid for realm1 even to realm2 related resources (not
very correct). 2) append nothing if resources belong to realm 2. (correct and easy), but when navigate from realm1 to realm2 you'll loose the session if cookies are disabled. 3) handle a sort of parent session that holds all sessions in realms, and then handle the url rewriting... (this requires more work)
kiuma
On Jan 14, 2008 1:24 PM, Andrea Chiumenti kiuma72@gmail.com wrote:
Edi, As a Murphi Law confirmation, session handling with session encoded into request doesn't work :/, I'm working on it. Modifications are of course backward compatible!
The importance on separate sessions depends only on how a person want to use hunchentoot, it has sense only if someone want to use hunchentoot as an application server so having sessions bound do 'deployed' applications.
I'll make the realm patch work very soon, cu,
kiuma
On Jan 14, 2008 8:52 AM, Edi Weitz < edi@agharta.de > wrote:
On Wed, 9 Jan 2008 11:27:21 +0100, "Andrea Chiumenti" < kiuma72@gmail.com> wrote:
I've no idea on how to do with cookies disabled, because I'm relatively new to Hunchentoot
Well, as I already said, I currently don't have the time to do this,
and I don't think it's a very important feature. So, you'll either have to send a complete and fully-tested patch that's backwards-compatible or you'll have to wait until I get around to do
it myself.
Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Please let me know, because I need these info to proceed with my project.
Behold
lest Edi's wrath be upon ye.
;) Leslie
On Wed, 16 Jan 2008 10:18:23 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
The behavior in url-rewriting is that, when switching from realm1 to realm2 the session is reset in realm2: this means (setf *session* nil) and (setf (session request) nil).
So this will make to create a new session for realm2 but it will maintain the session for realm1. Navigating inside the same realm maintains the session.
That means that switching realms without cookies will be different from switching realms with cookies? Hmm, not good.
Please let me know, because I need these info to proceed with my project.
I'm not really convinced yet that this is really a useful addition for Hunchentoot. Also, don't having much time to think about this, are you really sure this can't be done with the current session framework without the need to patch Hunchentoot or to write your own session code?
Anyway, if you need this for your own projects, don't wait for me, but rather write code that doesn't depend on a patched Hunchentoot. I'm too busy right now to make any promises about updates or patches.
Edi.
On Jan 16, 2008 6:20 PM, Edi Weitz edi@agharta.de wrote:
On Wed, 16 Jan 2008 10:18:23 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
The behavior in url-rewriting is that, when switching from realm1 to realm2 the session is reset in realm2: this means (setf *session* nil) and (setf (session request) nil).
So this will make to create a new session for realm2 but it will maintain the session for realm1. Navigating inside the same realm maintains the session.
That means that switching realms without cookies will be different from switching realms with cookies? Hmm, not good.
the only possibility is to rewrite/patch the url-rewriter
Please let me know, because I need these info to proceed with my project.
I'm not really convinced yet that this is really a useful addition for Hunchentoot.
Sorry, but are you joking ?? Suppose I'm the customer, I buy a web application from you, this application is a wonderful e-commerce application, and you use the "user" session key to store a user principal. I then "deploy" this web application on my well configured hunchentoot running on port 4242. Then I buy from SuperLispCoders L.t.d. another web application that is a web-log analyzer that has an administrative area. oops! cl-weblog uses "user" session key too, and for a totally different need and its structure is different too!! Please don't tell me to open another port, for policy reasons they are all closed and my boss told me to use the same hunchentoot instance!! ..... the story continue!
Also, don't having much time to think about this, are
you really sure this can't be done with the current session framework without the need to patch Hunchentoot or to write your own session code?
Anyway, if you need this for your own projects, don't wait for me, but rather write code that doesn't depend on a patched Hunchentoot. I'm too busy right now to make any promises about updates or patches.
Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, 16 Jan 2008 22:38:37 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
I'm not really convinced yet that this is really a useful addition for Hunchentoot.
Sorry, but are you joking ??
No.
On Jan 16, 2008 10:56 PM, Edi Weitz edi@agharta.de wrote:
On Wed, 16 Jan 2008 22:38:37 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
I'm not really convinced yet that this is really a useful addition for Hunchentoot.
Sorry, but are you joking ??
Hello Edi, As someone pointed out to me, the above sentence seems rude, my public apologizes because that was a really free translation from my language (I already don't know how to render it ;-)) . So please, if I offended you somehow, I beg your pardon. Anyway since my project seems the only with the need of different sessions, I'll try another approach that doesn't involve hunchentoot for my needs, before publishing the first commit. Have a nice day, kiuma
No. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Jan 17, 2008 8:58 AM, Andrea Chiumenti kiuma72@gmail.com wrote:
Anyway since my project seems the only with the need of different sessions, I'll try another approach that doesn't involve hunchentoot for my needs, before publishing the first commit.
I wonder why you can't get away with patching hunchentoot for your purposes, i.e. by re-defining those internal functions of hunchentoot that you need to change, and distribute the hunchentoot patches with your application (?). That way, you'll be able to publish whatever you have, and if you create a large enough user base that is using your software and annoyed by the way hunchentoot needs to be patched, Edi may be easier to convince.
-Hans
"Andrea Chiumenti" kiuma72@gmail.com writes:
Anyway since my project seems the only with the need of different sessions, I'll try another approach that doesn't involve hunchentoot for my needs, before publishing the first commit. Have a nice day, kiuma
I also have three SBCL/hunchentoot servers running on the same machine which could be replaced by one with the help of your patches. So, in principle I would be interested in this feature if it could be integrated in Hunchentoot nicely. However, even if such a version of Hunchentoot would be available I am not sure if running only one instance would be a good idea, since a bug in one application would wreak havoc on all.
[I must admit that I had no problems in asking our computing center for more open ports. If this would not have worked, I probably would have put my servers behind Apache/modlisp (which I probably will do anyway at some point, because people occasionally reported problems accessing my servers from places which allowed only connections on port 8080).]
Nicolas
Thanks for your replies, I'll go with what I've written then, so that who wants may evaluate the patches, (they'll be provided into a separate lisp file, the will override some hunchentoot functions). The modifications will be available in one day or two into claw project registered at common-lisp.net
For what concerning the example on port, it was just an example, to make present that in some environment, asking configuration modifications to the edp group of a cutomer, may result a pain (I speak for experience).
Thx for suggestions, Have a nice day,
kiuma On Jan 17, 2008 10:09 AM, Nicolas Neuss neuss@math.uni-karlsruhe.de wrote:
"Andrea Chiumenti" kiuma72@gmail.com writes:
Anyway since my project seems the only with the need of different sessions, I'll try another approach that doesn't involve hunchentoot for my needs, before publishing the first commit. Have a nice day, kiuma
I also have three SBCL/hunchentoot servers running on the same machine which could be replaced by one with the help of your patches. So, in principle I would be interested in this feature if it could be integrated in Hunchentoot nicely. However, even if such a version of Hunchentoot would be available I am not sure if running only one instance would be a good idea, since a bug in one application would wreak havoc on all.
[I must admit that I had no problems in asking our computing center for more open ports. If this would not have worked, I probably would have put my servers behind Apache/modlisp (which I probably will do anyway at some point, because people occasionally reported problems accessing my servers from places which allowed only connections on port 8080).]
Nicolas
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, 17 Jan 2008 08:58:33 +0100, "Andrea Chiumenti" kiuma72@gmail.com wrote:
As someone pointed out to me, the above sentence seems rude, my public apologizes because that was a really free translation from my language (I already don't know how to render it ;-)) . So please, if I offended you somehow, I beg your pardon.
Nah, no problem. I don't think it was rude and I wasn't offended. It's just as I said - I'm not convinced that this is really a good addition to Hunchentoot. I might be wrong, but at the moment I don't have the time to think about this more deeply.
I have a long-term plan to overhaul the internals of Hunchentoot and to make several things more user-configurable. Parallel sessions might fall out of this once it's done. But don't hold your breath - as I said, I'm busy...
Edi.
-
Andrea Chiumenti -
Edi Weitz -
Hans Hübner -
Leslie P. Polzer -
Nicolas Neuss -
Sohail Somani -
Vagif Verdi -
Volkan YAZICI