- Jamis
It means that chocolate chip and pumpkin cookies have been removed from
rails.
I'm so depressed ;)
Tim
- Jamis
--
Joe Eames
Software Alchemist
On Jul 19, 12:46 pm, Jeremy Nicoll <jnic...@goldnoteexpress.com>
wrote:
> I'm with Jamis on this one.
>
> - Jeremy Nicoll
>
> Joe Eames wrote:
> > oatmeal raisin. it's a cookie and you can pretend it's healthy. how
> > does it get any better than that?
>
> > On 7/19/07, *Jamis Buck* < ja...@37signals.com
> > <mailto:ja...@37signals.com>> wrote:
>
> > It's opinionation coming to play. The only cookie anyone should care
> > about is peanut butter. :)
>
> > - Jamis
>
> > On 7/19/07, Tim Harper <timchar...@gmail.com
> > <mailto:timchar...@gmail.com>> wrote:
>
> > > Jamis,
>
> > > It means that chocolate chip and pumpkin cookies have been
> > removed from
> > > rails.
>
> > > I'm so depressed ;)
>
> > > Tim
>
> > > -----Original Message-----
> > > From: ur...@googlegroups.com <mailto:ur...@googlegroups.com>
> > [mailto: ur...@googlegroups.com <mailto:ur...@googlegroups.com>] On
> > Behalf Of
> > > Jamis Buck
> > > Sent: Thursday, July 19, 2007 9:52 AM
> > > To: ur...@googlegroups.com <mailto:ur...@googlegroups.com>
> > > Subject: [urug] Re: http only cookies
>
> > > http-only? What does that mean? HTTP cookies are sent only via HTTP,
> > > so I'm not gleaning much meaning from the term "http-only cookies".
>
> > > - Jamis
>
> > > On 7/19/07, john < John.Staff2...@gmail.com
The article states that an http only cookie is one that is stored in
the browser but not accessible through javascript. A traditional
cookie is stored by the browser and associated with a domain. The next
time the browser makes a request to that domain (as long as the cookie
has not expired etc) the cookie is sent back to the server. A user's
session typically works using cookies. The typical scenario is this.
The server generates a random session ID which it sends to the browser
as a cookie. The browser stores the ID and sends it on subsequent
requests to identify who it is communicating with. This ID should be
treated like gold. If a nefarious individual gets a hold of it they
can manually duplicate the cookie in their own browser and take over
the users session (session hijacking). This could be particularly
disastrous if a hacker manages to obtain an administrators session ID
cookie.
How might someone go about obtaining such a session ID you ask? Say
you have a blog where you post articles and allow people to comment.
Some unscrupulous individual decides to mess around with you, they
post a comment to your blog with a snippet of javascript that reads
all the domain cookies and uses document.write to output an img or
other tag which results in a call to a server in his control
containing the cookie data that was read (a cross site scripting
attack). If your comment system does not remove such javascript the
next time you view your blog (his comment rather) your cookies
(potentially including your session id) are sent to him and he just
needs to search his logs to discover your session ID.
He then crafts a cookie with your session ID and proceeds to log into
your blog administrative interface and does whatever he sees fit with
your blog.
One way to protect yourself from this situation is to strip javascript
from untrusted sources. Another would be to make sure that sensitive
cookies are not accessible from javascript. Firefox seems to be
working to add support for the latter which in my opinion is a good
thing but no substitute for making sure you don't leave the door open
for XSS attacks by allowing javascript from untrusted sources.
Hope that clarifies things.
Anyone know if Rails sends session_id cookies as http only for
browsers that support it?
Lee
On 7/19/07, john <John.St...@gmail.com> wrote:
>
oatmeal raisin. it's a cookie and you can pretend it's healthy. how does it get any better than that?