Anton, I understand the security risks and I wasn't going to use the cookie directly as a means of verifying the user's status. But I need the cookie to at least tell me WHAT user is trying to access the site; from there I can check the user name against some authentication system to see if they have logged in.
So my question wasn't in regards to the design of my authentication system, but rather the means to access those variables where the tag code is written. I would love to have access to all the HTTP header variables, just need to know how :) On 10/9/07, Anton J Aylward <[EMAIL PROTECTED]> wrote: > Matt Hughes said the following on 10/09/2007 09:54 PM: > > How about accessing cookies from the model? > > > > I basically want my application to have two tags: > > > > <r:isLoggedIn> and <r:isLoggedOut> > > > > Where the Ruby code that implements those tags (in the models > > according to the tutorial) would check for the presence of certain > > cookies. But from my initial experiments, I don't have access to the > > cookies variable in the model code. > > > > > > Any ideas? > > Why not make it generic and allow access to ANY HTTP header? > > Add that to <r:if> .... > > All that useful stuff like remote host, address, port ... > > When it comes down to it, the cookie alone won't tell you if the user is > validated. In fact that's an assumption that will open up some security > holes :-( > > Try session_id and session_variable ... > > Actually, what I did for an e-commerce site was to have the session_id plus > a time-stamp in the cookie in encrypted form - so that 'time-out' cold be > done and so that the cookie wasn't the same every exchange. (The encryption > key had to change periodically as well which made it hairy!) The > session_id was not predictable - see how that is done TCP sequence numbers > in late model kernels. > > Some day I may get around to recoding this in Ruby/Rails ... > > But PLEASE! > Don't code up something that is a security CFM and make your site a target > for all manner of attacks and zombifications. Putting "isLoggedIn" or > equivilent (e.g. raw data or predictable session_id) in the cookie is a real > security risk. > > http://www.rorsecurity.info/ - Ruby on Rails Security Project > > http://www.owasp.org/index.php/OWASP_AppSec_FAQ - Gives good advice on how > to design the login process. > > http://rubythis.blogspot.com/2006/11/rails-security-checklist.html > > http://www.quarkruby.com/2007/9/20/ruby-on-rails-security-guide > > http://www.rorsecurity.info/2007/03/20/logingenerator-and-loginsugar-security-vulnerabilities/ > > -- > Anton J Aylward, CISSP, CISA <[EMAIL PROTECTED]> > System Integrity > Minister in the Church of St Sysiphus The Perplexed, > The patron saint of InfoSec > > > Anton J Aylward, CISSP, CISA <[EMAIL PROTECTED]> > System Integrity > http://si.on.ca - System Integrity > http://infosecblog.antonaylward.com - The InfoSec Blog > > > > -- > Genius is one per cent inspiration, ninety-nine per cent perspiration. > Thomas A. Edison, Harper's Monthly, 1932 > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
