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