Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Cookies not RESTful - need explaination

Expand Messages
  • Chuck Hinson
    ... I ve been struggling with authentication/authorization and how to fit it into the REST model... I m probably confusing several issues (and I m probably
    Message 1 of 26 , Jun 4, 2002
    • 0 Attachment
      Allan Doyle wrote:
      >
      > Cookies are out of band as far as REST is concerned, and are
      > downright anti-REST because you will probably never see the cookie
      > contents but those contents are responsible for a ton of information
      > transfer between client and server. If you moved the cookie info to a
      > URI-accessible location, then it would be RESTful. A big issue with
      > current practice (not with HTTP or REST) is that usually clients don't
      > have HTTP servers running in them or on their behalf so the server
      > can't get at client-side state with a simple GET. (c.f. the
      > "client-side shopping basket" statement above). This asymmetry also
      > impacts the ability to do decent asynchronous callbacks from the
      > server to the client.
      >

      I've been struggling with authentication/authorization and how to fit it
      into the REST model...

      I'm probably confusing several issues (and I'm probably unaware of others),
      but it seems very difficult to provide authentication and authorization
      without cookies or some similar mechanism - and I'm not sure I see a
      solution that doesn't just shift the problem (state-hiding) somewhere else.

      In all the examples I've seen, the resources are assumed to be publicly
      accessible. In the example above, the suggestion is to move the hidden
      state stored in a cookie to a URI-accessible location. However, once I've
      done that, I would think that I am then obliged to ensure that only the user
      who owns that information is able to retrieve it. How do I do that if I
      cant also issue the user a token (cookie) that they can then use as proof of
      identity?

      My first thoughts were that you could use HTTPS with client certs to provide
      identity, but it seems that you've only shifted the problem around. Instead
      of providing proof of identity with a cookie, your providing it with a
      certificate. Or maybe using a cookie for authentication doesnt violate the
      no-hidden-state rule.

      --Chuck
    • Mark Baker
      ... It s already there, with HTTP authentication. A 401 response to a HTTP request tells the client to provide a header with the authentication info, next time
      Message 2 of 26 , Jun 4, 2002
      • 0 Attachment
        On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote:
        > I've been struggling with authentication/authorization and how to fit it
        > into the REST model...

        It's already there, with HTTP authentication.

        A 401 response to a HTTP request tells the client to provide a header
        with the authentication info, next time it does that request. On
        subsequent requests, that header is always included, making the
        interaction stateless.

        MB
        --
        Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
        Ottawa, Ontario, CANADA. distobj@...
        http://www.markbaker.ca http://www.idokorro.com
      • Bill de h├ôra
        ... Hash: SHA1 ... He wants you to store the basket details on the client using URIs to manage the representations. The cost is coordinating client and server
        Message 3 of 26 , Jun 4, 2002
        • 0 Attachment
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA1


          > -----Original Message-----
          > From: Roger L. Costello [mailto:costello@...]
          > Sent: 04 June 2002 13:29
          > To: rest-discuss@yahoogroups.com; costello@...
          > Subject: [rest-discuss] Cookies not RESTful - need explaination
          >
          >
          > Hi Folks,
          >
          > Below is an except from Fielding's REST dissertation,
          > describing why cookies are not RESTful. Can someone explain
          > what he is saying here?
          >
          > "Likewise, the use of cookies to identify a user-specific
          > 'shopping basket' within a server-side database could be more
          > efficiently implemented by defining the semantics of shopping
          > items within the hypermedia data formats, allowing the user
          > agent to select and store those items within their own
          > client-side shopping basket, complete with a URI to be used
          > for check-out when the client is ready to purchase."

          He wants you to store the basket details on the client using URIs
          to manage the representations. The cost is coordinating client and
          server software. I imagine that cost would less if the client could
          also act as a server, i.e. you could get at the basket using HTTP
          methods. It would be efficient insofar as you'd stop routing around
          your local CPU to do processing on the server's. Cookies may not be
          restful, but the more appealing argument to some might be that they
          could throw away their enterprise class web server infrastructure,
          load balancers et al and apportion some of the costs to the client.
          I haven't heard an argument for rest based on reducing server side
          costs, it would be an interesting one.

          Bill



          -----BEGIN PGP SIGNATURE-----
          Version: PGP 7.0.4

          iQA/AwUBPPzvUuaWiFwg2CH4EQLwzwCgiY4ZxB7zVXpORPRBiKWcumiFUd4AoJl4
          7IZp/H7jS9Ne4clLuCChzSB8
          =C8E3
          -----END PGP SIGNATURE-----
        • S. Mike Dierken
          ... From: Mark Baker ... I m confused - a cookie is part of the HTTP message, both request and response. The client can read and write them
          Message 4 of 26 , Jun 4, 2002
          • 0 Attachment
            ----- Original Message -----
            From: "Mark Baker" <distobj@...>
            >
            > You know that cookies are stateful, right? That is, they make it so
            > that there isn't enough information in the HTTP message to understand
            > what it does, because it depends on the information represented by
            > the cookie which is invisible to everybody but the server.
            I'm confused - a cookie is part of the HTTP message, both request and
            response.
            The client can read and write them and so can the server.
            And anyway, combining information from the request and server-only state
            isn't a bad thing - security permissions, etc. do this all the time.

            The problem I have is that they are often used to qualify the URI - for
            example
            http://my.example.org/startpage.asp is the same URI for everyone, but the
            page - the 'actual' resource - is different based on the value of the
            cookie. This makes the sample URI unsharable, uncacheable, etc. - which is
            good or bad depending on what you are trying to do.
            They are also often used to identify the user, or at least a user's
            server-side session.
          • S. Mike Dierken
            ... From: Chuck Hinson ... The examples I write have the assumption that permissions exist on the server for the resources. Any message
            Message 5 of 26 , Jun 4, 2002
            • 0 Attachment
              ----- Original Message -----
              From: "Chuck Hinson" <hinson@...>

              >
              > In all the examples I've seen, the resources are assumed to be publicly
              > accessible.
              The examples I write have the assumption that permissions exist on the
              server for the resources.
              Any message that has a cookie in it can be captured and re-played with the
              cookie intact, so the message itself is just as 'public' as the URI only.

              > In the example above, the suggestion is to move the hidden
              > state stored in a cookie to a URI-accessible location.
              I wouldn't call it 'state' that is in the cookie, the data usually is used
              as values for lookup on the server side.

              > However, once I've
              > done that, I would think that I am then obliged to ensure that only the
              user
              > who owns that information is able to retrieve it.
              Yes, that would be a good thing.

              > How do I do that if I cant also issue the user a token (cookie)
              > that they can then use as proof of identity?
              This token isn't proof of identity. It can be captured, copied, and replayed
              elsewhere. Cookie based approaches are just breaking the URI into two pieces
              and hoping that the Bad Guys don't capture both pieces. Since that is not
              doable, people make one piece very transient, which only reduces the window
              of opportunity.
              Now that I think about it, using HTTPS would minimize the chance that other
              people will find the cookie.

              >
              > My first thoughts were that you could use HTTPS with client certs to
              provide
              > identity, but it seems that you've only shifted the problem around.
              Instead
              > of providing proof of identity with a cookie, your providing it with a
              > certificate. Or maybe using a cookie for authentication doesnt violate
              the
              > no-hidden-state rule.
              >
              I think there is an interesting design question here regarding coordination
              costs of establishing trust:
              - server provides tokens for identity
              - client provides tokens for identity

              I'll have to think about this for a while.
            • Chuck Hinson
              ... Hmm. I guess I already knew that. However, the lack of support by browsers for anything other than Basic Auth pretty much eliminates the Authorization
              Message 6 of 26 , Jun 4, 2002
              • 0 Attachment
                Mark Baker wrote:
                > On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote:
                >
                >>I've been struggling with authentication/authorization and how to fit it
                >>into the REST model...
                >
                >
                > It's already there, with HTTP authentication.
                >
                > A 401 response to a HTTP request tells the client to provide a header
                > with the authentication info, next time it does that request. On
                > subsequent requests, that header is always included, making the
                > interaction stateless.
                >

                Hmm. I guess I already knew that. However, the lack of support by browsers
                for anything other than Basic Auth pretty much eliminates the Authorization
                header as a solution today. (Once again, reality interferes...)

                Given that, it would seem that using a cookie for authentication is a
                reasonable alternative -- the spec say use the Authorization header;
                browsers and servers dont support that very well, so I'll use a header that
                they do support and that happens to be a cookie.

                --Chuck


                > MB
              • Mark Baker
                ... Yes, but the information necessary to understand what a message with a cookie means, is not part of the message. GET /foo HTTP/1.1 has one meaning for all
                Message 7 of 26 , Jun 4, 2002
                • 0 Attachment
                  On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote:
                  > I'm confused - a cookie is part of the HTTP message, both request and
                  > response.

                  Yes, but the information necessary to understand what a message with
                  a cookie means, is not part of the message.

                  GET /foo HTTP/1.1

                  has one meaning for all time, which you can lookup in RFC 2616.

                  GET /foo HTTP/1.1
                  Cookie: bar=goo

                  can have many meanings depending upon what magic that cookie induces
                  in the behaviour of the server. You can't look up what it means
                  anywhere.

                  > The problem I have is that they are often used to qualify the URI - for
                  > example
                  > http://my.example.org/startpage.asp is the same URI for everyone, but
                  > the
                  > page - the 'actual' resource - is different based on the value of the
                  > cookie. This makes the sample URI unsharable, uncacheable, etc. - which
                  > is
                  > good or bad depending on what you are trying to do.
                  > They are also often used to identify the user, or at least a user's
                  > server-side session.

                  Right, that's a special case of the problem I described above; if you
                  allow a message's meaning to change (be it the identified-resource, the
                  authorization info, etc..) depending upon information not in the message
                  itself, then you can very easily do the Wrong Thing.

                  MB
                  --
                  Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                  Ottawa, Ontario, CANADA. distobj@...
                  http://www.markbaker.ca http://www.idokorro.com
                • Paul Prescod
                  ... I think you mean information in the message or *REFERENCED* by the message through a derferencerable URI. Am I right? For instance it is not wrong for a
                  Message 8 of 26 , Jun 4, 2002
                  • 0 Attachment
                    Mark Baker wrote:
                    >
                    >...
                    >
                    > Right, that's a special case of the problem I described above; if you
                    > allow a message's meaning to change (be it the identified-resource, the
                    > authorization info, etc..) depending upon information not in the message
                    > itself, then you can very easily do the Wrong Thing.

                    I think you mean "information in the message or *REFERENCED* by the
                    message through a derferencerable URI." Am I right? For instance it is
                    not wrong for a "purchase now" message to point to a shopping cart URI.
                    As long as the two do not change you could understand that message a
                    hundred years from now on a totally different device.

                    Paul Prescod
                  • Mark Baker
                    ... No, in the message itself. If the meaning of the message depends on information you get from dereferencing a URI (or anything else outside the message),
                    Message 9 of 26 , Jun 4, 2002
                    • 0 Attachment
                      On Tue, Jun 04, 2002 at 02:47:41PM -0700, Paul Prescod wrote:
                      > > Right, that's a special case of the problem I described above; if you
                      > > allow a message's meaning to change (be it the identified-resource, the
                      > > authorization info, etc..) depending upon information not in the message
                      > > itself, then you can very easily do the Wrong Thing.
                      >
                      > I think you mean "information in the message or *REFERENCED* by the
                      > message through a derferencerable URI." Am I right?

                      No, in the message itself. If the meaning of the message depends
                      on information you get from dereferencing a URI (or anything else
                      outside the message), then it is stateful.

                      > For instance it is
                      > not wrong for a "purchase now" message to point to a shopping cart URI.
                      > As long as the two do not change you could understand that message a
                      > hundred years from now on a totally different device.

                      Right, because the meaning of "purchase this shopping cart now" doesn't
                      depend on what you get by dereferencing the shopping cart URI.

                      MB
                      --
                      Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                      Ottawa, Ontario, CANADA. distobj@...
                      http://www.markbaker.ca http://www.idokorro.com
                    • Roger L. Costello
                      ... Let me see if I understand what you are saying Mark: if the HTTP header contains information (e.g., cookie information) that is used by the server
                      Message 10 of 26 , Jun 4, 2002
                      • 0 Attachment
                        Mark Baker wrote:
                        >
                        > On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote:
                        > > I'm confused - a cookie is part of the HTTP message, both request and
                        > > response.
                        >
                        > Yes, but the information necessary to understand what a message with
                        > a cookie means, is not part of the message.
                        >
                        > GET /foo HTTP/1.1
                        >
                        > has one meaning for all time, which you can lookup in RFC 2616.
                        >
                        > GET /foo HTTP/1.1
                        > Cookie: bar=goo
                        >
                        > can have many meanings depending upon what magic that cookie induces
                        > in the behaviour of the server. You can't look up what it means
                        > anywhere.

                        Let me see if I understand what you are saying Mark: if the HTTP header
                        contains information (e.g., cookie information) that is used by the
                        server application then that is not RESTful. However, if we were to
                        move the (e.g., cookie) information into the HTTP message body, then it
                        would be RESTful. Is that it? That doesn't seem reasonable since the
                        HTTP header contains a lot of information that a server application will
                        typically use, such as the content type that the client will accept
                        (e.g., text/html), and many other things. These HTTP headers induces
                        behaviour in the server application. Taking this argument to its
                        logical conclusion, then I conclude that no HTTP message can ever be
                        RESTful, unless it has no HTTP headers, since HTTP headers by their very
                        nature induces behaviour in the server application. Yes?

                        To restate my earlier question: what exactly does it mean to be
                        stateless? In light of the above, does it mean that all information is
                        carried in the HTTP message body? That is, the server application's
                        behaviour is not influenced by anything in the HTTP header?

                        Sorry to be so dense on this. However, I feel that it is a critical
                        issue that I want to make certain I fully understand as I go out into
                        the world to preach the merits of REST. /Roger
                      • S. Mike Dierken
                        ... From: Chuck Hinson ... browsers ... Authorization ... The systems I m envisioning go way beyond the browser - and then the full
                        Message 11 of 26 , Jun 4, 2002
                        • 0 Attachment
                          ----- Original Message -----
                          From: "Chuck Hinson" <hinson@...>

                          >
                          > Hmm. I guess I already knew that. However, the lack of support by
                          browsers
                          > for anything other than Basic Auth pretty much eliminates the
                          Authorization
                          > header as a solution today. (Once again, reality interferes...)
                          The systems I'm envisioning go way beyond the browser - and then the full
                          potential of HTTP is available. Build a different user agent, or if you
                          really must, use components that do provide full HTTP access
                          (IXMLHTTPRequest in IE and others).

                          >
                          > Given that, it would seem that using a cookie for authentication is a
                          > reasonable alternative -- the spec say use the Authorization header;
                          > browsers and servers dont support that very well, so I'll use a header
                          that
                          > they do support and that happens to be a cookie.
                          It isn't reasonable, but there is little alternative. I'm amazed the browser
                          world has gone this long without extending FORM to support users entering
                          credentials.
                          A big reason sites use FORMs is to control the UI. It shouldn't be a big
                          deal to for FORM to specify that it is user input for credentials at the
                          specified URI.
                        • Mark Baker
                          ... No ... ... Hmm, no. By message , I mean the entire HTTP message; request line, headers, and body. Think about taking an HTTP message, and storing it to
                          Message 12 of 26 , Jun 4, 2002
                          • 0 Attachment
                            On Tue, Jun 04, 2002 at 07:16:47PM -0400, Roger L. Costello wrote:
                            > Let me see if I understand what you are saying Mark: if the HTTP header
                            > contains information (e.g., cookie information) that is used by the
                            > server application then that is not RESTful.

                            No ...

                            > However, if we were to
                            > move the (e.g., cookie) information into the HTTP message body, then it
                            > would be RESTful. Is that it?

                            Hmm, no. By "message", I mean the entire HTTP message; request line,
                            headers, and body.

                            Think about taking an HTTP message, and storing it to disk for 20
                            years. When you "reconstitute" it at that time, will people still
                            know what it means? If it used cookies, they won't, because some
                            information necessary to understanding it was on the server, and it
                            expired years ago.

                            Compare it to FTP, if that helps. If I pickle the (logical) command
                            "RETR foo.zip" to disk, and reconstitute it 10 minutes later, nobody
                            will know what it means because they don't know what the current
                            directory is, and hence which foo.zip to retrieve. FTP is a stateful
                            protocol.

                            > Sorry to be so dense on this. However, I feel that it is a critical
                            > issue that I want to make certain I fully understand as I go out into
                            > the world to preach the merits of REST. /Roger

                            It's definitely a critical issue, as statelessness is so key to
                            visibility and reliability.

                            MB
                            --
                            Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
                            Ottawa, Ontario, CANADA. distobj@...
                            http://www.markbaker.ca http://www.idokorro.com
                          • Seth Ladd
                            Some thoughts... ... An HTTP message can certainly be RESTful. You can accomplish this by correctly using a URI to reference a real, true object. The headers
                            Message 13 of 26 , Jun 5, 2002
                            • 0 Attachment
                              Some thoughts...


                              > behaviour in the server application. Taking this argument to its
                              > logical conclusion, then I conclude that no HTTP message can ever be
                              > RESTful, unless it has no HTTP headers, since HTTP headers by their very
                              > nature induces behaviour in the server application. Yes?


                              An HTTP message can certainly be RESTful. You can accomplish this by
                              correctly using a URI to reference a real, true object. The headers can
                              still be there, and are very helpful as metadata and instructions on how
                              to handle the message itself.

                              For instance, REST likes to transfer state of objects. But, some
                              objects can be represented many different ways. For example, a daily
                              report can be represented as a PDF, HTML, XML, etc. That's just the
                              physical form. The logical object itself is the same. Now, this object
                              might have a URI of http://example.org/finance/report/2002/06/05. Using
                              that URI, I can GET and SET that report throughout time and space. But
                              how do I know what I'm getting? HTTP is the protocol we're using, so
                              HTTP headers are introduced. Think of the headers like the envolope.
                              They tell us more info about the resource. That info isn't needed to
                              identify the object (that's done with the URI). So the HTTP header will
                              say "Content-type: application/pdf" to indicate what bytes are being
                              sent. This doesn't violate REST (IMO) since we haven't obfuscated the
                              object identifier.


                              > To restate my earlier question: what exactly does it mean to be
                              > stateless? In light of the above, does it mean that all information is
                              > carried in the HTTP message body? That is, the server application's
                              > behaviour is not influenced by anything in the HTTP header?

                              It might help for your understanding of REST to divorce yourself from
                              HTTP a bit. REST is a paradigm and a set of patterns. HTTP can be used
                              for an implementation of REST, but isn't the perfect embodiment of REST.

                              To be stateless means to carry all information needed for the request
                              along with the request. That request must be able to stand alone. If
                              the process requires three messages in a certain order, each depending
                              on the first one, that is not stateless.

                              Hope I didn't confuse things more. :)

                              Seth
                            • Philip Eskelin
                              [snip] ... For obvious reasons, any mention of the word envelope in RESTful discussions makes me shudder....gives me nightmares where employees from
                              Message 14 of 26 , Jun 5, 2002
                              • 0 Attachment
                                [snip]
                                Seth wrote:
                                > HTTP headers are introduced. Think of the headers like the envolope.

                                For obvious reasons, any mention of the word "envelope" in RESTful discussions
                                makes me shudder....gives me nightmares where employees from Microsoft and IBM
                                force-feed me bars of soap until I wake up in a cold sweat ;-)

                                -Philip
                              • Seth Ladd
                                ... Yeah, except SOAP can be used to communicate a RESTful protocol. It s all about how you use the transport mechanism. Seth
                                Message 15 of 26 , Jun 5, 2002
                                • 0 Attachment
                                  Philip Eskelin wrote:
                                  > [snip]
                                  > Seth wrote:
                                  >
                                  >>HTTP headers are introduced. Think of the headers like the envolope.
                                  >
                                  >
                                  > For obvious reasons, any mention of the word "envelope" in RESTful discussions
                                  > makes me shudder....gives me nightmares where employees from Microsoft and IBM
                                  > force-feed me bars of soap until I wake up in a cold sweat ;-)

                                  Yeah, except SOAP can be used to communicate a RESTful protocol. It's
                                  all about how you use the transport mechanism.

                                  Seth
                                • Philip Eskelin
                                  ... discussions ... IBM ... I ve always thought it would be interesting if someone sponsored a tunneling contest to see who can tunnel the most protocols in
                                  Message 16 of 26 , Jun 5, 2002
                                  • 0 Attachment
                                    Seth wrote:
                                    > Philip Eskelin wrote:
                                    > > [snip]
                                    > > Seth wrote:
                                    > >
                                    > > >HTTP headers are introduced. Think of the headers like the envolope.
                                    > >
                                    > >
                                    > > For obvious reasons, any mention of the word "envelope" in RESTful
                                    discussions
                                    > > makes me shudder....gives me nightmares where employees from Microsoft and
                                    IBM
                                    > > force-feed me bars of soap until I wake up in a cold sweat ;-)
                                    >
                                    > Yeah, except SOAP can be used to communicate a RESTful protocol. It's
                                    > all about how you use the transport mechanism.

                                    I've always thought it would be interesting if someone sponsored a "tunneling
                                    contest" to see who can tunnel the most protocols in the most creative fashion.
                                    Someone might try to say "hello world" across a network by distributing dynamic
                                    data exchange between windows on separate machines by taking a DDE execute
                                    message and marshaling it as COM invocation using an RPC tunneled through
                                    canonicalized, base 64-encoded XML-RPC messages communicated via a RESTful
                                    implementation built with Python on SOAP running on HTTP implemented over
                                    TCP/IP, where a proxy server sitting inside a firewall receives the request,
                                    unmarshals each of its layers, and faxes the message to a gorilla who takes the
                                    paper and feeds it into a scanner that performs OCR to interpret the message and
                                    send it to a Windows desktop running a NetDDE server that dispatches the request
                                    by writing the message to a temporary HTML file containing JavaScript loaded by
                                    a web browser that displays the original "hello world" in a message box.

                                    -Phil
                                  • Gordon Weakliem
                                    ... Is it me, or does this sound strangely close to the thinking that brought about Don Box s notorious HTTP is Dead keynote? Replace REST with SOAP in the
                                    Message 17 of 26 , Jun 6, 2002
                                    • 0 Attachment
                                      >It might help for your understanding of REST to divorce yourself from
                                      >HTTP a bit. REST is a paradigm and a set of patterns. HTTP can be used
                                      >for an implementation of REST, but isn't the perfect embodiment of REST.

                                      Is it me, or does this sound strangely close to the thinking that brought about Don Box's notorious "HTTP is Dead" keynote? Replace REST with SOAP in the last sentence, and what do you have? Put another way, is there a meaningful non-HTTP implementation of REST out in the wild? Sorry, but I really tripped on this statement. Would anybody care to expand on it?
                                    • S. Mike Dierken
                                      ... From: Gordon Weakliem ... about Don Box s notorious HTTP is Dead ... have? Put another way, is ... expand on it? I think of
                                      Message 18 of 26 , Jun 6, 2002
                                      • 0 Attachment
                                        ----- Original Message -----
                                        From: "Gordon Weakliem" <gweakliem@...>

                                        >
                                        > Is it me, or does this sound strangely close to the thinking that brought
                                        about Don Box's notorious "HTTP is Dead"
                                        > keynote? Replace REST with SOAP in the last sentence, and what do you
                                        have? Put another way, is
                                        > there a meaningful non-HTTP implementation of REST out in the wild?
                                        > Sorry, but I really tripped on this statement. Would anybody care to
                                        expand on it?

                                        I think of SQL based systems as something with a lot of REST-like qualities.
                                        They are much better at the jobs they were designed for than a REST based
                                        system, but REST is better at jobs /it/ was designed for.
                                      Your message has been successfully submitted and would be delivered to recipients shortly.