From Daniel.Berger at qwest.com Fri Oct 5 09:38:57 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 5 Oct 2007 08:38:57 -0500 Subject: Session handling busted on Oracle Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E73@ITOMAE2KM01.AD.QINTRA.COM> Hi, Ruby 1.8.6 (one-click) Camping 1.5 I'd submit this as a bug, but the tracker says I'm forbidden, so here you go. The first problem is that the sql to create the sessions table is broken. This is what it tried to send: CREATE TABLE sessions ( id NUMBER(38) NOT NULL PRIMARY KEY (38), --> Problem here hashid VARCHAR2(32), created_at DATE, ivars CLOB DEFAULT empty_clob() ) The problem is that second "(38)" after "PRIMARY KEY". So, I removed that and created the table manually. The next problem was a missing Oracle sequence (which I had no idea was required, but ok). I figured out (by stepping through oci8.rb) that the name of the sequence should be "sessions_seq". For that I used the following snippet: CREATE SEQUENCE ACS_SUPPORT.SESSIONS_SEQ START WITH 50 MAXVALUE 999999999999999999999999999 MINVALUE 0 NOCYCLE CACHE 50 NOORDER; Unfortunately, there are still problems, and here's where I'm not sure what's happening: [2007-10-04 15:53:24] INFO WEBrick 1.3.1 [2007-10-04 15:53:24] INFO ruby 1.8.6 (2007-03-13) [i386-mswin32] [2007-10-04 15:53:24] INFO WEBrick::HTTPServer#start: pid=1736 port=3301 [2007-10-04 15:53:31] ERROR NoMethodError: undefined method `[]=' for nil:NilClass C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:21:in `[]=' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:110:in `service' (eval):44:in `run' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/reloader.rb:117:i n `run' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/webrick.rb:45:in `service' C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' C:/ruby/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' C:/ruby/lib/ruby/1.8/webrick/server.rb:95:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `each' C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:23:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:82:in `start' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/bin/camping:244 C:/ruby/bin/camping:16:in `load' C:/ruby/bin/camping:16 So, for whatever reason, it's not pulling the sessions_seq.nextval properly. At least, that's my guess. I haven't debugged further as I sorta lost energy at that point. Any ideas? Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Daniel.Berger at qwest.com Fri Oct 5 10:08:16 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 5 Oct 2007 09:08:16 -0500 Subject: Cookie session handling? Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> Hi, I and a few folks on #camping thought it would be nice to have either cookie based or file based session handling. This would eliminate the need for creating a sessions table in the database (or a sequence), which feels too heavy for a lightweight framework like Camping anyway. Plus, we can more easily avoid nasty adapter errors. :) The general consensus was to create a separate camping/session/cookie.rb (or file.rb) file. That way users could include the type of session handling they want via require + include. require 'camping/session/cookie' module MyCamp include Camping::Session::Cookie # or File, or whatever end Or something along those lines. Whaddya think? Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From zimbatm at oree.ch Fri Oct 5 11:54:26 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Fri, 5 Oct 2007 17:54:26 +0200 Subject: Session handling busted on Oracle In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E73@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72E73@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: Hi Daniel, I think that I have corrected that last week changeset [226]. The problem was that Session uses it's own kind of id (hashid) and that by default, ActiveRecord uses an incremental version. See : http://code.whytheluckystiff.net/camping/changeset/226 Please tell me if I introduced any regression. -- Cheers, zimbatm From zimbatm at oree.ch Fri Oct 5 12:08:12 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Fri, 5 Oct 2007 18:08:12 +0200 Subject: Cookie session handling? In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: Hi Daniel, I like the idea pretty much. What do you think of simply using a Camping::H that is process-persistent ? -- Cheers, zimbatm From julian.tarkhanov at gmail.com Fri Oct 5 13:27:37 2007 From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov) Date: Fri, 5 Oct 2007 19:27:37 +0200 Subject: Session handling busted on Oracle In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFBE72E73@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <6D239BF7-74A3-4584-B7A6-A485F9702A01@gmail.com> On 5-okt-2007, at 17:54, Jonas Pfenniger wrote: > I think that I have corrected that last week changeset [226]. The > problem was that Session uses it's own kind of id (hashid) and that by > default, ActiveRecord uses an incremental version. > > See : http://code.whytheluckystiff.net/camping/changeset/226 > > Please tell me if I introduced any regression. I am for the proposal of having multiple session drivers, but totally _not_ for the proposal of abolishing the db sessions. I routinely run Camping in parallel fashion (multiplexed dispatchers) and I also store data that does not fit in the 4K cookie limit in the session (see Pasaporte, where the whole OpenID request is piggybacked in the session storage). I also like the idea that all Camping apps store their session in _one_ record, with many apps on one domain this would not be easily solvable because 4k is too small for one app, let alone many apps. So I am for a PStore-based session but not for cookie-based sessions. Their introduction in Rails among others revealed some problems that exist with this approach. The changeset did not introduce any regressions for me but I will keep my Set-Cookie workaround for a while, at least until Camping 1.6 hits the streets -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl From Daniel.Berger at qwest.com Fri Oct 5 16:51:13 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 5 Oct 2007 15:51:13 -0500 Subject: Session handling busted on Oracle In-Reply-To: Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E7B@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: camping-list-bounces at rubyforge.org > [mailto:camping-list-bounces at rubyforge.org] On Behalf Of > Jonas Pfenniger > Sent: Friday, October 05, 2007 9:54 AM > To: camping-list at rubyforge.org > Subject: Re: Session handling busted on Oracle > > > Hi Daniel, > > I think that I have corrected that last week changeset [226]. > The problem was that Session uses it's own kind of id > (hashid) and that by default, ActiveRecord uses an > incremental version. > > See : http://code.whytheluckystiff.net/camping/changeset/226 > > Please tell me if I introduced any regression. Doesn't work. Same error basically: [2007-10-05 14:46:17] ERROR NoMethodError: undefined method `[]=' for nil:NilClass C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:24:in `[]=' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:129:in `service' (eval):44:in `run' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/reloader.rb:117:i n `run' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/webrick.rb:45:in `service' C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' C:/ruby/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' C:/ruby/lib/ruby/1.8/webrick/server.rb:95:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `each' C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:23:in `start' C:/ruby/lib/ruby/1.8/webrick/server.rb:82:in `start' C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/bin/camping:244 C:/ruby/bin/camping:16:in `load' Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From why at whytheluckystiff.net Fri Oct 5 17:16:08 2007 From: why at whytheluckystiff.net (why the lucky stiff) Date: Fri, 5 Oct 2007 16:16:08 -0500 Subject: Cookie session handling? In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <20071005211608.GI64652@beekeeper.hobix.com> On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: > I like the idea pretty much. What do you think of simply using a > Camping::H that is process-persistent ? Sure, and maybe it doesn't really need to be process-persistent. Yes, that would be how Camping would want us to do it. _why From evan at cloudbur.st Fri Oct 5 17:54:51 2007 From: evan at cloudbur.st (Evan Weaver) Date: Fri, 5 Oct 2007 17:54:51 -0400 Subject: Cookie session handling? In-Reply-To: <20071005211608.GI64652@beekeeper.hobix.com> References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> <20071005211608.GI64652@beekeeper.hobix.com> Message-ID: > Sure, and maybe it doesn't really need to be process-persistent. Wouldn't that limit you to non-load-balanced apps, since you could only have one simultaneous process if you want session consistency? Evan On 10/5/07, why the lucky stiff wrote: > On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: > > I like the idea pretty much. What do you think of simply using a > > Camping::H that is process-persistent ? > > Sure, and maybe it doesn't really need to be process-persistent. > Yes, that would be how Camping would want us to do it. > > _why > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -- Evan Weaver Cloudburst, LLC From aredridel at nbtsc.org Fri Oct 5 18:06:50 2007 From: aredridel at nbtsc.org (Aria Stewart) Date: Fri, 5 Oct 2007 16:06:50 -0600 Subject: Cookie session handling? In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> <20071005211608.GI64652@beekeeper.hobix.com> Message-ID: <50E70C48-C5DD-4A86-A655-3AF45B3F82D6@nbtsc.org> On Oct 5, 2007, at 3:54 PM, Evan Weaver wrote: >> Sure, and maybe it doesn't really need to be process-persistent. > > Wouldn't that limit you to non-load-balanced apps, since you could > only have one simultaneous process if you want session consistency? > > Evan > Can always make it easy and well-defined to override. s/H/DHT with the right API/ and let 'em go. From zimbatm at oree.ch Sun Oct 7 12:55:40 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Sun, 7 Oct 2007 18:55:40 +0200 Subject: Cookie session handling? In-Reply-To: <20071005211608.GI64652@beekeeper.hobix.com> References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> <20071005211608.GI64652@beekeeper.hobix.com> Message-ID: 2007/10/5, why the lucky stiff : > On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: > > I like the idea pretty much. What do you think of simply using a > > Camping::H that is process-persistent ? > > Sure, and maybe it doesn't really need to be process-persistent. How can it be less than process-persistent ? Instance persistent ? Or is it irony and it means not persistent at all ? :p -- Cheers, zimbatm From zimbatm at oree.ch Sun Oct 7 13:00:13 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Sun, 7 Oct 2007 19:00:13 +0200 Subject: Session handling busted on Oracle In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E7B@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72E7B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: Weird, the ivars field should have been defined in the "generate" function. Did you drop the session schema on beforehand ? -- Cheers, zimbatm From julian.tarkhanov at gmail.com Sun Oct 7 13:46:58 2007 From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov) Date: Sun, 7 Oct 2007 19:46:58 +0200 Subject: Cookie session handling? In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> <20071005211608.GI64652@beekeeper.hobix.com> Message-ID: <43796D3D-C4CB-4A90-90D0-F2804A5E2B89@gmail.com> On 7-okt-2007, at 18:55, Jonas Pfenniger wrote: > 2007/10/5, why the lucky stiff : >> On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: >>> I like the idea pretty much. What do you think of simply using a >>> Camping::H that is process-persistent ? >> >> Sure, and maybe it doesn't really need to be process-persistent. > > How can it be less than process-persistent ? Instance persistent ? Or > is it irony and it means not persistent at all ? :p As mentioned previously, you have cliented sessions with signing - but then you are limited to the cookie size minus the signature. Personally I'm all for different session drivers - some kind of agreement what a session should and sould not do perhaps? Then you can plug session/cookies, session/files or session/db at your heart's content. The thing of note is that I think it should be configurable per app (because some apps have different session size requirements, and some apps would not want to reveal the session content in a cookie). -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl From evan at cloudbur.st Sun Oct 7 18:08:43 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sun, 7 Oct 2007 18:08:43 -0400 Subject: Cookie session handling? In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> <20071005211608.GI64652@beekeeper.hobix.com> Message-ID: I took it to mean "persistent across processes" not "persistent per-process". Evan On 10/7/07, Jonas Pfenniger wrote: > 2007/10/5, why the lucky stiff : > > On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote: > > > I like the idea pretty much. What do you think of simply using a > > > Camping::H that is process-persistent ? > > > > Sure, and maybe it doesn't really need to be process-persistent. > > How can it be less than process-persistent ? Instance persistent ? Or > is it irony and it means not persistent at all ? :p > > -- > Cheers, > zimbatm > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Sun Oct 7 18:11:26 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sun, 7 Oct 2007 18:11:26 -0400 Subject: Cookie session handling? In-Reply-To: <43796D3D-C4CB-4A90-90D0-F2804A5E2B89@gmail.com> References: <7524A45A1A5B264FA4809E2156496CFBE72E76@ITOMAE2KM01.AD.QINTRA.COM> <20071005211608.GI64652@beekeeper.hobix.com> <43796D3D-C4CB-4A90-90D0-F2804A5E2B89@gmail.com> Message-ID: > Personally I'm all for different session drivers - some kind of > agreement what a session should and sould not do perhaps? > Then you can plug session/cookies, session/files or session/db at > your heart's content. The thing of note is that > I think it should be configurable per app (because some apps have > different session size requirements, and some apps would > not want to reveal the session content in a cookie). I agree; a suite of session drivers would be a useful addition. If no one else steps up, eventually I would be able to write them, but I am very busy right now and don't have an immediate need for different session types. All right, back to the woods. Evan -- Evan Weaver Cloudburst, LLC From bcorrigan78 at gmail.com Mon Oct 8 11:31:36 2007 From: bcorrigan78 at gmail.com (Brian Corrigan) Date: Mon, 8 Oct 2007 11:31:36 -0400 Subject: Camping-list Digest, Vol 18, Issue 1 In-Reply-To: References: Message-ID: UNSUBSCRIBE On Oct 5, 2007, at 1:27 PM, camping-list-request at rubyforge.org wrote: > Send Camping-list mailing list submissions to > camping-list at rubyforge.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://rubyforge.org/mailman/listinfo/camping-list > or, via email, send a message with subject or body 'help' to > camping-list-request at rubyforge.org > > You can reach the person managing the list at > camping-list-owner at rubyforge.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Camping-list digest..." > > > Today's Topics: > > 1. Re: putting away HashWithIndifferentAccess (Jonas Pfenniger) > 2. Re: PUT (and friends) bug? (Brendan Taylor) > 3. Re: PUT (and friends) bug? (cdr) > 4. Re: PUT (and friends) bug? (Jonas Pfenniger) > 5. Session handling busted on Oracle (Berger, Daniel) > 6. Cookie session handling? (Berger, Daniel) > 7. Re: Session handling busted on Oracle (Jonas Pfenniger) > 8. Re: Cookie session handling? (Jonas Pfenniger) > 9. Re: Session handling busted on Oracle (Julian 'Julik' Tarkhanov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 29 Sep 2007 01:16:18 +0200 > From: "Jonas Pfenniger" > Subject: Re: putting away HashWithIndifferentAccess > To: camping-list at rubyforge.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > 2007/9/27, why the lucky stiff : >> Well, case-sensitiveness would be a prob with 1.5 as well. Since >> @env.HTTP_HOST will work and @env.http_host will not. > > True. So what do you think of the attached patch ? It removes roughly > 50 octets to camping.rb and seems to work pretty well, except for apps > that used :symbols to access H members. > > -- > Cheers, > zimbatm > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: camping-no-HWIA.diff > Type: text/x-diff > Size: 4911 bytes > Desc: not available > Url : http://rubyforge.org/pipermail/camping-list/attachments/ > 20070929/baa051db/attachment-0001.bin > > ------------------------------ > > Message: 2 > Date: Fri, 28 Sep 2007 19:23:57 -0600 > From: Brendan Taylor > Subject: Re: PUT (and friends) bug? > To: camping-list at rubyforge.org > Message-ID: <20070929012357.GB29057 at nyarlathotep> > Content-Type: text/plain; charset="us-ascii" > > On Fri, Sep 28, 2007 at 03:22:23PM -0400, Nathaniel Talbott wrote: >> As far as I can tell, sending an actual HTTP PUT request to a Camping >> app will never parse the params out of the request body - or am I >> going nuts? This code seems to say only POST's will parse the request >> body: >> >> elsif @method == "post" and \ >> e.CONTENT_TYPE == "application/x-www-form-urlencoded" >> q.u(C.qsp(@in.read)) >> end > > The @method == "post" test is a vestige of when Camping just parsed > anything that was POSTed. I didn't really think about it when I > submitted the patch to test the Content-Type. > > AFAIK there's no reason not to remove the method test altogether; use > those bytes for something more useful. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: not available > Url : http://rubyforge.org/pipermail/camping-list/attachments/ > 20070928/d90429e5/attachment-0001.bin > > ------------------------------ > > Message: 3 > Date: Sat, 29 Sep 2007 08:50:47 -0400 > From: cdr <_ at whats-your.name> > Subject: Re: PUT (and friends) bug? > To: camping-list at rubyforge.org > Message-ID: <20070929125047.GA2732 at replic.net> > Content-Type: text/plain; charset=us-ascii > >> The @method == "post" test is a vestige of when Camping just parsed >> anything that was POSTed. I didn't really think about it when I >> submitted the patch to test the Content-Type. >> >> AFAIK there's no reason not to remove the method test altogether; use >> those bytes for something more useful. > > agreed. you can handle request body -> @input for any method except > the ones that explicitly forbid request bodies (GET, HEAD, OPTIONS/ > TRACE?..), in one swoop. > > the MIME test must stay, of course. otherwise when you add support > for other MIMEs using #service it silenty fails trying to parse > JSON or whatever as QSVars.. > > >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > > ------------------------------ > > Message: 4 > Date: Sun, 30 Sep 2007 22:27:45 +0200 > From: "Jonas Pfenniger" > Subject: Re: PUT (and friends) bug? > To: camping-list at rubyforge.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Okay, I'll remove the test then. > > -- > Cheers, > zimbatm > > > ------------------------------ > > Message: 5 > Date: Fri, 5 Oct 2007 08:38:57 -0500 > From: "Berger, Daniel" > Subject: Session handling busted on Oracle > To: > Message-ID: > <7524A45A1A5B264FA4809E2156496CFBE72E73 at ITOMAE2KM01.AD.QINTRA.COM> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > Ruby 1.8.6 (one-click) > Camping 1.5 > > I'd submit this as a bug, but the tracker says I'm forbidden, so here > you go. > > The first problem is that the sql to create the sessions table is > broken. This is what it tried to send: > > CREATE TABLE sessions ( > id NUMBER(38) NOT NULL PRIMARY KEY (38), --> Problem here > hashid VARCHAR2(32), > created_at DATE, > ivars CLOB DEFAULT empty_clob() > ) > > The problem is that second "(38)" after "PRIMARY KEY". So, I removed > that and created the table manually. > > The next problem was a missing Oracle sequence (which I had no idea > was > required, but ok). I figured out (by stepping through oci8.rb) that > the > name of the sequence should be "sessions_seq". For that I used the > following snippet: > > CREATE SEQUENCE ACS_SUPPORT.SESSIONS_SEQ > START WITH 50 > MAXVALUE 999999999999999999999999999 > MINVALUE 0 > NOCYCLE > CACHE 50 > NOORDER; > > Unfortunately, there are still problems, and here's where I'm not sure > what's happening: > > [2007-10-04 15:53:24] INFO WEBrick 1.3.1 > [2007-10-04 15:53:24] INFO ruby 1.8.6 (2007-03-13) [i386-mswin32] > [2007-10-04 15:53:24] INFO WEBrick::HTTPServer#start: pid=1736 > port=3301 > [2007-10-04 15:53:31] ERROR NoMethodError: undefined method `[]=' for > nil:NilClass > > C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb: > 21:in > `[]=' > > C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb: > 110:in > `service' > (eval):44:in `run' > > C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/reloader.rb: > 117:i > n `run' > > C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/webrick.rb: > 45:in > `service' > C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' > C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' > C:/ruby/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' > C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in `start' > C:/ruby/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' > C:/ruby/lib/ruby/1.8/webrick/server.rb:95:in `start' > C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `each' > C:/ruby/lib/ruby/1.8/webrick/server.rb:92:in `start' > C:/ruby/lib/ruby/1.8/webrick/server.rb:23:in `start' > C:/ruby/lib/ruby/1.8/webrick/server.rb:82:in `start' > C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/bin/camping:244 > C:/ruby/bin/camping:16:in `load' > C:/ruby/bin/camping:16 > > So, for whatever reason, it's not pulling the sessions_seq.nextval > properly. At least, that's my guess. I haven't debugged further as I > sorta lost energy at that point. > > Any ideas? > > Regards, > > Dan > > > This communication is the property of Qwest and may contain > confidential or > privileged information. Unauthorized use of this communication is > strictly > prohibited and may be unlawful. If you have received this > communication > in error, please immediately notify the sender by reply e-mail and > destroy > all copies of the communication and any attachments. > > > ------------------------------ > > Message: 6 > Date: Fri, 5 Oct 2007 09:08:16 -0500 > From: "Berger, Daniel" > Subject: Cookie session handling? > To: > Message-ID: > <7524A45A1A5B264FA4809E2156496CFBE72E76 at ITOMAE2KM01.AD.QINTRA.COM> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > I and a few folks on #camping thought it would be nice to have either > cookie based or file based session handling. This would eliminate the > need for creating a sessions table in the database (or a sequence), > which feels too heavy for a lightweight framework like Camping anyway. > Plus, we can more easily avoid nasty adapter errors. :) > > The general consensus was to create a separate camping/session/ > cookie.rb > (or file.rb) file. That way users could include the type of session > handling they want via require + include. > > require 'camping/session/cookie' > > module MyCamp > include Camping::Session::Cookie # or File, or whatever > end > > Or something along those lines. Whaddya think? > > Regards, > > Dan > > > This communication is the property of Qwest and may contain > confidential or > privileged information. Unauthorized use of this communication is > strictly > prohibited and may be unlawful. If you have received this > communication > in error, please immediately notify the sender by reply e-mail and > destroy > all copies of the communication and any attachments. > > > ------------------------------ > > Message: 7 > Date: Fri, 5 Oct 2007 17:54:26 +0200 > From: "Jonas Pfenniger" > Subject: Re: Session handling busted on Oracle > To: camping-list at rubyforge.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Daniel, > > I think that I have corrected that last week changeset [226]. The > problem was that Session uses it's own kind of id (hashid) and that by > default, ActiveRecord uses an incremental version. > > See : http://code.whytheluckystiff.net/camping/changeset/226 > > Please tell me if I introduced any regression. > > -- > Cheers, > zimbatm > > > ------------------------------ > > Message: 8 > Date: Fri, 5 Oct 2007 18:08:12 +0200 > From: "Jonas Pfenniger" > Subject: Re: Cookie session handling? > To: camping-list at rubyforge.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Daniel, > > I like the idea pretty much. What do you think of simply using a > Camping::H that is process-persistent ? > > -- > Cheers, > zimbatm > > > ------------------------------ > > Message: 9 > Date: Fri, 5 Oct 2007 19:27:37 +0200 > From: Julian 'Julik' Tarkhanov > Subject: Re: Session handling busted on Oracle > To: camping-list at rubyforge.org > Message-ID: <6D239BF7-74A3-4584-B7A6-A485F9702A01 at gmail.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On 5-okt-2007, at 17:54, Jonas Pfenniger wrote: > >> I think that I have corrected that last week changeset [226]. The >> problem was that Session uses it's own kind of id (hashid) and >> that by >> default, ActiveRecord uses an incremental version. >> >> See : http://code.whytheluckystiff.net/camping/changeset/226 >> >> Please tell me if I introduced any regression. > > I am for the proposal of having multiple session drivers, but totally > _not_ for the proposal of abolishing > the db sessions. I routinely run Camping in parallel fashion > (multiplexed dispatchers) and I also store > data that does not fit in the 4K cookie limit in the session (see > Pasaporte, where the whole OpenID request > is piggybacked in the session storage). I also like the idea that all > Camping apps store their session in _one_ record, > with many apps on one domain this would not be easily solvable > because 4k is too small for one app, let alone many apps. > So I am for a PStore-based session but not for cookie-based sessions. > Their introduction in Rails among others revealed some problems that > exist with this approach. > > The changeset did not introduce any regressions for me but I will > keep my Set-Cookie workaround for a while, at least until Camping 1.6 > hits the streets > > -- > Julian 'Julik' Tarkhanov > please send all personal mail to > me at julik.nl > > > > > ------------------------------ > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > End of Camping-list Digest, Vol 18, Issue 1 > ******************************************* From Daniel.Berger at qwest.com Mon Oct 8 13:18:51 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 8 Oct 2007 12:18:51 -0500 Subject: Session handling busted on Oracle In-Reply-To: Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E8A@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: camping-list-bounces at rubyforge.org > [mailto:camping-list-bounces at rubyforge.org] On Behalf Of > Jonas Pfenniger > Sent: Sunday, October 07, 2007 11:00 AM > To: camping-list at rubyforge.org > Subject: Re: Session handling busted on Oracle > > > Weird, the ivars field should have been defined in the > "generate" function. Did you drop the session schema on beforehand ? I dropped both the table and the sequence (and rebuilt them manually again). I uninstalled the camping gem, and installed the latest camping gem from source. Same error. This was the sql I used for the table: CREATE TABLE sessions ( id NUMBER(38) NOT NULL PRIMARY KEY, hashid VARCHAR2(32), created_at DATE, ivars CLOB DEFAULT empty_clob() ) Was there something else I should have used? Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From zimbatm at oree.ch Mon Oct 8 14:23:24 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Mon, 8 Oct 2007 20:23:24 +0200 Subject: Session handling busted on Oracle In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E8A@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72E8A@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2007/10/8, Berger, Daniel : > Was there something else I should have used? Well technically, the id field is not necessary anymore. I don't know how AR will react if it is set. Also, are you sure that you are using camping from trunk ? Btw, here is the schema I have on sqlite : CREATE TABLE sessions ("hashid" varchar(32) NOT NULL, "created_at" datetime DEFAULT NULL, "ivars" text DEFAULT NULL); -- Cheers, zimbatm From Daniel.Berger at qwest.com Mon Oct 8 15:05:20 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 8 Oct 2007 14:05:20 -0500 Subject: Session handling busted on Oracle In-Reply-To: Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E8B@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: camping-list-bounces at rubyforge.org > [mailto:camping-list-bounces at rubyforge.org] On Behalf Of > Jonas Pfenniger > Sent: Monday, October 08, 2007 12:23 PM > To: camping-list at rubyforge.org > Subject: Re: Session handling busted on Oracle > > > 2007/10/8, Berger, Daniel : > > Was there something else I should have used? > > Well technically, the id field is not necessary anymore. I > don't know how AR will react if it is set. Also, are you sure > that you are using camping from trunk ? > > Btw, here is the schema I have on sqlite : > > CREATE TABLE sessions ("hashid" varchar(32) NOT NULL, > "created_at" datetime DEFAULT NULL, "ivars" text DEFAULT NULL); Ok, this is what I went with: CREATE TABLE sessions ( hashid varchar(32) NOT NULL, created_at date DEFAULT NULL, ivars varchar(256) DEFAULT NULL ); It seems to be working, so I'm guessing that the id field was indeed the culprit. We'll see how it goes. Many thanks! Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Daniel.Berger at qwest.com Tue Oct 9 13:15:11 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 9 Oct 2007 12:15:11 -0500 Subject: Session handling busted on Oracle In-Reply-To: Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E92@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: camping-list-bounces at rubyforge.org > [mailto:camping-list-bounces at rubyforge.org] On Behalf Of > Jonas Pfenniger > Sent: Monday, October 08, 2007 12:23 PM > To: camping-list at rubyforge.org > Subject: Re: Session handling busted on Oracle > > > 2007/10/8, Berger, Daniel : > > Was there something else I should have used? > > Well technically, the id field is not necessary anymore. I > don't know how AR will react if it is set. Also, are you sure > that you are using camping from trunk ? > > Btw, here is the schema I have on sqlite : > > CREATE TABLE sessions ("hashid" varchar(32) NOT NULL, > "created_at" datetime DEFAULT NULL, "ivars" text DEFAULT NULL); Upon further review that isn't going to work. You can't set the @state variable without an id field. Camping Problem! FastPath::Controllers::Login.POST ActiveRecord::StatementInvalid OCIError: ORA-00904: "ID": invalid identifier: UPDATE sessions SET hashid = 'iNr6UPnc3KjbQBxZwktujSIENXWIhzfd', ivars = '--- !map:HashWithIndifferentAccess FastPath: !map:HashWithIndifferentAccess cuid: true ', created_at = '2007-10-09 11:00:32' WHERE id = NULL: C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/con nection_adapters/abstract_adapter.rb:128:in `log' C:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/con nection_adapters/oracle_adapter.rb:222:in `execute' ... Suggestions? Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Daniel.Berger at qwest.com Tue Oct 9 13:57:26 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 9 Oct 2007 12:57:26 -0500 Subject: Session handling busted on Oracle In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E92@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E93@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: camping-list-bounces at rubyforge.org > [mailto:camping-list-bounces at rubyforge.org] On Behalf Of > Berger, Daniel > Sent: Tuesday, October 09, 2007 11:15 AM > To: camping-list at rubyforge.org > Subject: RE: Session handling busted on Oracle > > > > -----Original Message----- > > From: camping-list-bounces at rubyforge.org > > [mailto:camping-list-bounces at rubyforge.org] On Behalf Of > > Jonas Pfenniger > > Sent: Monday, October 08, 2007 12:23 PM > > To: camping-list at rubyforge.org > > Subject: Re: Session handling busted on Oracle > > > > > > 2007/10/8, Berger, Daniel : > > > Was there something else I should have used? > > > > Well technically, the id field is not necessary anymore. I > > don't know how AR will react if it is set. Also, are you sure > > that you are using camping from trunk ? > > > > Btw, here is the schema I have on sqlite : > > > > CREATE TABLE sessions ("hashid" varchar(32) NOT NULL, > > "created_at" datetime DEFAULT NULL, "ivars" text DEFAULT NULL); > > Upon further review that isn't going to work. You can't set > the @state variable without an id field. Upon further review of the previous review, it seems the problem is not the ID field, but the datatype of the ivars field. I went with this: CREATE TABLE sessions ( id number primary key, hashid varchar(32) NOT NULL, created_at date DEFAULT NULL, ivars varchar(256) DEFAULT NULL ); So far, so good.... Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From david.gurba at gmail.com Tue Oct 9 14:09:25 2007 From: david.gurba at gmail.com (David Gurba) Date: Tue, 9 Oct 2007 11:09:25 -0700 Subject: Session handling busted on Oracle In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E93@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72E93@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <24A4E4FA-E9F8-4330-872E-BF964019AF9A@gmail.com> after a bit of fuss ... i fully shipped off EES at 8am today to Jason at Bren. I'm dabbling in drupal at the moment in some core themeing components. I know that I will need at least 2 other things to do this week besides IDs site ... Sakai themeing or ASP->PHP are others items i'm aware of ... but not sure as to the resource locations. -dg On Oct 9, 2007, at 10:57 AM, Berger, Daniel wrote: > > >> -----Original Message----- >> From: camping-list-bounces at rubyforge.org >> [mailto:camping-list-bounces at rubyforge.org] On Behalf Of >> Berger, Daniel >> Sent: Tuesday, October 09, 2007 11:15 AM >> To: camping-list at rubyforge.org >> Subject: RE: Session handling busted on Oracle >> >> >>> -----Original Message----- >>> From: camping-list-bounces at rubyforge.org >>> [mailto:camping-list-bounces at rubyforge.org] On Behalf Of >>> Jonas Pfenniger >>> Sent: Monday, October 08, 2007 12:23 PM >>> To: camping-list at rubyforge.org >>> Subject: Re: Session handling busted on Oracle >>> >>> >>> 2007/10/8, Berger, Daniel : >>>> Was there something else I should have used? >>> >>> Well technically, the id field is not necessary anymore. I >>> don't know how AR will react if it is set. Also, are you sure >>> that you are using camping from trunk ? >>> >>> Btw, here is the schema I have on sqlite : >>> >>> CREATE TABLE sessions ("hashid" varchar(32) NOT NULL, >>> "created_at" datetime DEFAULT NULL, "ivars" text DEFAULT NULL); >> >> Upon further review that isn't going to work. You can't set >> the @state variable without an id field. > > Upon further review of the previous review, it seems the problem is > not > the ID field, but the datatype of the ivars field. I went with this: > > CREATE TABLE sessions ( > id number primary key, > hashid varchar(32) NOT NULL, > created_at date DEFAULT NULL, > ivars varchar(256) DEFAULT NULL > ); > > So far, so good.... > > Regards, > > Dan > > > This communication is the property of Qwest and may contain > confidential or > privileged information. Unauthorized use of this communication is > strictly > prohibited and may be unlawful. If you have received this > communication > in error, please immediately notify the sender by reply e-mail and > destroy > all copies of the communication and any attachments. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From julian.tarkhanov at gmail.com Tue Oct 9 15:05:24 2007 From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov) Date: Tue, 9 Oct 2007 21:05:24 +0200 Subject: Session handling busted on Oracle In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E93@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72E93@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <3FEC36FF-8D8C-4AD8-8BE3-43532E41FB9F@gmail.com> On Oct 9, 2007, at 7:57 PM, Berger, Daniel wrote: > > So far, so good.... I know it's a minority concern, but maybe it is a good idea to make that ID field present and use it accordingly. -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/camping-list/attachments/20071009/cdd6d4c8/attachment.html From zimbatm at oree.ch Tue Oct 9 18:09:25 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Wed, 10 Oct 2007 00:09:25 +0200 Subject: Camping and sessions proposal. Message-ID: Hi Campers, from the discussions gathered around, the current Camping sessions don't seem to be satisfying. ActiveRecord doesn't seem to handle hashid as an identifier, plus it doesn't seem to be fully consistent across the various RDBMS. On the other hand, the scope of the project does not permit to implement all kind of client persistence. Secure sessions with cross-process persistence is not that easy. You probably would like to link the sessions ids with the clients's IP or other kind of magic to make sure that XSS attacks are not possible. So here is what I propose : Camping will only provide an in-process session store with no real security built-in. See it as a hack-ready example that will allow you to make your internal apps work quickly (ak. no DB dependency). And for the more demanding, I hope that a parallel project can be started that provides more serious sessions (and other extensions?) handling. Ah, and I have attached a working example of how it would look like for peer-review. -- Cheers, zimbatm -------------- next part -------------- A non-text attachment was scrubbed... Name: session.rb Type: application/octet-stream Size: 2907 bytes Desc: not available Url : http://rubyforge.org/pipermail/camping-list/attachments/20071010/a30e2093/attachment-0001.obj From julian.tarkhanov at gmail.com Tue Oct 9 20:52:48 2007 From: julian.tarkhanov at gmail.com (Julian 'Julik' Tarkhanov) Date: Wed, 10 Oct 2007 02:52:48 +0200 Subject: Camping and sessions proposal. In-Reply-To: References: Message-ID: <0E2C6BF7-D5B9-406B-A212-F6B0464E19A7@gmail.com> On 10-okt-2007, at 0:09, Jonas Pfenniger wrote: > ActiveRecord doesn't seem to handle > hashid as an identifier, plus it doesn't seem to be fully consistent > across the various RDBMS. Only if you want to totally insist and not give it an ID then yes, it becomes a kind of a nuisance (your insistance is not justified though, as I mentioned in the ticket) because an integer is actually quite big. You gain little on the cleanness side, but you lose on the implementation and compatibility. > On the other hand, the scope of the project > does not permit to implement all kind of client persistence. +1 > So here is what I propose : Camping will only provide an in-process > session store with no real security built-in. See it as a hack-ready > example that will allow you to make your internal apps work quickly > (ak. no DB dependency). -1 If we sooo want to dump the DB, why not use PStore? I think multiprocess sessions are a must. Be aware that the RAM is not rubberized either. I like the implementation with load_state / save_state but I wonder: a) in-mem sessions are nasty, please don't b) how is that supposed to work with many applications on one server? which application decides which session driver is going to be used? If you ask me, I'd say sessions should stay with the DB (also considering that people are using them and there are session records in the wild). Give AR that ID and let it shut up :-) -- Julian 'Julik' Tarkhanov please send all personal mail to me at julik.nl From aredridel at nbtsc.org Wed Oct 10 12:09:46 2007 From: aredridel at nbtsc.org (Aria Stewart) Date: Wed, 10 Oct 2007 10:09:46 -0600 Subject: Camping and sessions proposal. In-Reply-To: <0E2C6BF7-D5B9-406B-A212-F6B0464E19A7@gmail.com> References: <0E2C6BF7-D5B9-406B-A212-F6B0464E19A7@gmail.com> Message-ID: On Oct 9, 2007, at 6:52 PM, Julian 'Julik' Tarkhanov wrote: > > On 10-okt-2007, at 0:09, Jonas Pfenniger wrote: >> ActiveRecord doesn't seem to handle >> hashid as an identifier, plus it doesn't seem to be fully consistent >> across the various RDBMS. > Only if you want to totally insist and not give it an ID then yes, it > becomes a kind of a nuisance (your insistance is not > justified though, as I mentioned in the ticket) because an integer is > actually quite big. > You gain little on the cleanness side, but you lose on the > implementation and compatibility. Yeah, AR demands an ID for most cases, and complains bitterly without. > >> On the other hand, the scope of the project >> does not permit to implement all kind of client persistence. > +1 ++ > >> So here is what I propose : Camping will only provide an in-process >> session store with no real security built-in. See it as a hack-ready >> example that will allow you to make your internal apps work quickly >> (ak. no DB dependency). > -1 > If we sooo want to dump the DB, why not use PStore? I think > multiprocess sessions are a must. Be aware that the RAM is not > rubberized either. > I like the implementation with load_state / save_state but I wonder: > a) in-mem sessions are nasty, please don't > b) how is that supposed to work with many applications on one server? > which application decides which session driver is going to be used? > > If you ask me, I'd say sessions should stay with the DB (also > considering that people are using them and there are session records > in the wild). > Give AR that ID and let it shut up :-) > Agreed -- though I actually need both in-memory sessions and on-disk. I'm using Net::IMAP, with persistent connections, and those are obviously not marshallable. Making it easy to create either based on the hooks camping provides is the best way I can think of. I'd love to have camping not actually create sessions on its own, but provide a session lib that works when required, like camping/ session.rb does now (ish); I'd love to have a version that doesn't require active_record, but most of my apps do at least use an sqlite database anyway. Keep camping light, move sessions as far out of the core as possible! Aria From why at whytheluckystiff.net Wed Oct 10 20:43:04 2007 From: why at whytheluckystiff.net (why the lucky stiff) Date: Wed, 10 Oct 2007 19:43:04 -0500 Subject: Camping and sessions proposal. In-Reply-To: References: <0E2C6BF7-D5B9-406B-A212-F6B0464E19A7@gmail.com> Message-ID: <20071011004304.GX64652@beekeeper.hobix.com> On Wed, Oct 10, 2007 at 10:09:46AM -0600, Aria Stewart wrote: > Keep camping light, move sessions as far out of the core as possible! I'd be okay leaving sessions out. I think zimbatm's Hash is great, because it's peewee and it gets the basic methods across for everyone else to override. If you're using more than one process for a Camping app, then you're probably crazy enough to prescribe your own potions. _why From lists at tipogral.hu Thu Oct 11 01:07:24 2007 From: lists at tipogral.hu (Nagy Bence) Date: Thu, 11 Oct 2007 07:07:24 +0200 Subject: Camping and sessions proposal. In-Reply-To: References: <0E2C6BF7-D5B9-406B-A212-F6B0464E19A7@gmail.com> Message-ID: <470DAF8C.40304@tipogral.hu> I am using a slightly different session modul with a small and dirty Camping hack for implemeting the Remember me function (used on http://dekk.hu/). @headers["Set-Cookie"]=@cookies.map{|k,v|"#{k}=#{k=~/_sid$/?v:C.escape(v)};#{"max-age=0;"if !v}path=#{self/'/'}"if v!=@k[k]}-[nil]; Camping does not escape a cookie variable if its name ends with "_sid", so i can add after the session_id a max_age value as described below in remember_me and forget_me functions. (The "application" function gets only the name of the the app.) module Camping module WigwamSession include Camping::Helpers def sessioncookie "#{application.to_s.downcase}_sid" end def remember_me @cookies[sessioncookie] = @session_id + ';max-age=31536000' end def forget_me @cookies[sessioncookie] &&= @session_id + ';max-age=0' end def service(*a) session = Camping::Models::WigwamSession.find_by_sessionid @cookies[sessioncookie] if @cookies[sessioncookie] if session @session_id = session.sessionid @state = session.variables else @session_id = [*0..31].map { ([*'A'..'Z'] + [*'a'..'z'] + [*'0'..'1'])[rand(62)] }.join @state = Camping::H[] end @cookies[sessioncookie] = @session_id state = @state.dup s = super(*a) if @state.empty? session.destroy if session elsif @state != state unless session Camping::Models::WigwamSession.create :sessionid => @session_id, :variables => @state else session.variables = @state session.save end end s end end end The possibility of adding "max-age" value for a cookie in the new version of Camping without hack the original source would be really great... Greetings, Bence -- Nagy Bence -> Tipogr?l | www.tipogral.hu -> Tipokert | www.tipokert.hu -> Dekk | www.dekk.hu -> Magyar Grafika | www.mgonline.hu -> H?rkapu | www.hirkapu.hu From lists at tipogral.hu Mon Oct 15 04:31:23 2007 From: lists at tipogral.hu (Nagy Bence) Date: Mon, 15 Oct 2007 10:31:23 +0200 Subject: Something is wrong with Camping::H in the svn version Message-ID: <4713255B.8090301@tipogral.hu> Dear All, I got az error message with the svn version of Camping under FastCGI NoMethodError undefined method `user_id' for {"user_id"=>2}:HashWithIndifferentAccess: The call was a simple "User.find @state.user_id" in my login controller... The following libraries are loaded manually: action_controller, action_view, mime/types, camping, camping/mab, camping/db, redcloth, erubis, htmlentities. With the old gem version and running on localhost with the camping command works everything fine. Greetings, Bence -- Nagy Bence -> Tipogr?l | www.tipogral.hu -> Tipokert | www.tipokert.hu -> Dekk | www.dekk.hu -> Magyar Grafika | www.mgonline.hu -> H?rkapu | www.hirkapu.hu From zimbatm at oree.ch Mon Oct 15 08:24:45 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Mon, 15 Oct 2007 14:24:45 +0200 Subject: Something is wrong with Camping::H in the svn version In-Reply-To: <4713255B.8090301@tipogral.hu> References: <4713255B.8090301@tipogral.hu> Message-ID: Hi Nagy, you should drop your session table once. Camping::H now inherits from Hash but your sessions data still use HashWithIndifferentAccess. -- Cheers, zimbatm From lists at tipogral.hu Mon Oct 15 08:48:25 2007 From: lists at tipogral.hu (Nagy Bence) Date: Mon, 15 Oct 2007 14:48:25 +0200 Subject: Something is wrong with Camping::H in the svn version In-Reply-To: References: <4713255B.8090301@tipogral.hu> Message-ID: <47136199.2070707@tipogral.hu> Dear zimbatm, > you should drop your session table once. Camping::H now inherits from > Hash but your sessions data still use HashWithIndifferentAccess. > problem solved... Thanks! Greetings, Bence -- Nagy Bence -> Tipogr?l | www.tipogral.hu -> Tipokert | www.tipokert.hu -> Dekk | www.dekk.hu -> Magyar Grafika | www.mgonline.hu -> H?rkapu | www.hirkapu.hu From clifford.heath at gmail.com Fri Oct 19 08:45:07 2007 From: clifford.heath at gmail.com (Clifford Heath) Date: Fri, 19 Oct 2007 22:45:07 +1000 Subject: X-Sendfile, static files, windows Message-ID: Jeremy, I found your old message with this title. I struck the same thing, where the current drive wasn't the same as the drive I wanted to serve (some) files from. So here's the patch to add to lib/mongrel/handlers.rb contains class DirHandler. I added two things, first to initialize: def initialize(path, listing_allowed=true, index_html="index.html") @abs = path == "/" # Absolute paths are allowed @path = File.expand_path(path) ... next to method can_serve, which should start with this: def can_serve(path_info) req_path = HttpRequest.unescape(path_info) # Add path prefix, except to absolute Windows paths: req_path = File.join(@path,req_path) if (!@abs || req_path =~ % r{\a[A-Z]:[/^\\]}i) # Expand it to an absolute path: req_path = File.expand_path req_path if File.exist? req_path .... Essentially this says if absolute paths are allowed and path_info has a drive letter, don't add the initial path. This should get into an official mongrel release sometime... Clifford Heath, Data Constellation. From simon at rozet.name Tue Oct 23 13:54:15 2007 From: simon at rozet.name (Simon Rozet) Date: Tue, 23 Oct 2007 19:54:15 +0200 Subject: Weird application/x-www-form-urlencoded bug Message-ID: <8878c9770710231054l403d691w8f89bf163484bb84@mail.gmail.com> Hello, I experienced a weird bug today, while implementing an AtomPub server. I pasted all the story and bug details here : http://p.caboo.se/110125 It maybe be related to http://code.whytheluckystiff.net/camping/ticket/142 ... I am using - mongrel 1.0.1 - camping 1.5 Cheers, -- Simon Rozet From zimbatm at oree.ch Wed Oct 24 05:02:52 2007 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Wed, 24 Oct 2007 11:02:52 +0200 Subject: Weird application/x-www-form-urlencoded bug In-Reply-To: <8878c9770710231054l403d691w8f89bf163484bb84@mail.gmail.com> References: <8878c9770710231054l403d691w8f89bf163484bb84@mail.gmail.com> Message-ID: 2007/10/23, Simon Rozet : > Hello, > > I experienced a weird bug today, while implementing an AtomPub server. > I pasted all the story and bug details here : http://p.caboo.se/110125 > > It maybe be related to http://code.whytheluckystiff.net/camping/ticket/142 ... > > I am using > - mongrel 1.0.1 > - camping 1.5 Hi Simon, can you try to reproduce your problem with the svn code ? -- Cheers, zimbatm From manfred at gmail.com Wed Oct 24 05:25:21 2007 From: manfred at gmail.com (Manfred Stienstra) Date: Wed, 24 Oct 2007 11:25:21 +0200 Subject: Weird application/x-www-form-urlencoded bug In-Reply-To: References: <8878c9770710231054l403d691w8f89bf163484bb84@mail.gmail.com> Message-ID: >> I experienced a weird bug today, while implementing an AtomPub >> server. >> I pasted all the story and bug details here : http://p.caboo.se/ >> 110125 If I understand correctly you're posting XML with Content-Type: application/x-www-form-urlencoded? That's not a very good idea because it triggers the form decoding code in Camping. Manfred From whateley at gmail.com Wed Oct 24 10:17:14 2007 From: whateley at gmail.com (Brendan Taylor) Date: Wed, 24 Oct 2007 08:17:14 -0600 Subject: Weird application/x-www-form-urlencoded bug In-Reply-To: <8878c9770710231054l403d691w8f89bf163484bb84@mail.gmail.com> References: <8878c9770710231054l403d691w8f89bf163484bb84@mail.gmail.com> Message-ID: <20071024141714.GF6717@nyarlathotep.ed.shawcable.net> On Tue, Oct 23, 2007 at 07:54:15PM +0200, Simon Rozet wrote: > Hello, > > I experienced a weird bug today, while implementing an AtomPub server. > I pasted all the story and bug details here : http://p.caboo.se/110125 > > It maybe be related to http://code.whytheluckystiff.net/camping/ticket/142 ... Hi Simon. Camping 1.5 tries to parse everything that's POSTed as application/x-www-form-urlencoded. The SVN version is fixed, see http://code.whytheluckystiff.net/camping/changeset/188 . (Once you've upgraded you'll need to POST your Atom Entry with the correct mimetype, too :) ) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/camping-list/attachments/20071024/8406cb50/attachment-0001.bin From simon at rozet.name Wed Oct 24 13:17:53 2007 From: simon at rozet.name (Simon Rozet) Date: Wed, 24 Oct 2007 19:17:53 +0200 Subject: Weird application/x-www-form-urlencoded bug In-Reply-To: <20071024141714.GF6717@nyarlathotep.ed.shawcable.net> References: <8878c9770710231054l403d691w8f89bf163484bb84@mail.gmail.com> <20071024141714.GF6717@nyarlathotep.ed.shawcable.net> Message-ID: <8878c9770710241017h761052d2s4f59dcfa6c120ef7@mail.gmail.com> On 10/24/07, Brendan Taylor wrote: > On Tue, Oct 23, 2007 at 07:54:15PM +0200, Simon Rozet wrote: > > Hello, > > > > I experienced a weird bug today, while implementing an AtomPub server. > > I pasted all the story and bug details here : http://p.caboo.se/110125 > > > > It maybe be related to http://code.whytheluckystiff.net/camping/ticket/142 ... > > Hi Simon. Camping 1.5 tries to parse everything that's POSTed as > application/x-www-form-urlencoded. The SVN version is fixed, see > http://code.whytheluckystiff.net/camping/changeset/188 . OK! I just upgraded to the SVN trunk and it works, thanks :-) > (Once you've upgraded you'll need to POST your Atom Entry with the > correct mimetype, too :) ) Sure. I don't know why I was sending it at application/x-form-www-form-urlencoded instead of application/atom+xml;type=entry -- Simon Rozet From Daniel.Berger at qwest.com Wed Oct 24 13:30:58 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 24 Oct 2007 12:30:58 -0500 Subject: Will there be a new release soon? Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72F0A@ITOMAE2KM01.AD.QINTRA.COM> Hi, Is there going to be a 1.5.1 release anytime soon? Seems like there have been enough changes in SVN to warrant one and I prefer to use only "released" code in production. It gives me warmer, fuzzier feelings than using svn/trunk. :) Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.