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

Re: Pretty URLs, sessions, and no cookies

Expand Messages
  • Michael Schuerig
    ... [snip] ... Authentication information is usually enough. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
    Message 1 of 28 , Jun 10, 2008
    • 0 Attachment
      On Wednesday 11 June 2008, Josh Sled wrote:
      > Michael Schuerig <michael@...> writes:
      > > On Wednesday 11 June 2008, Aristotle Pagaltzis wrote:
      > >> * Michael Schuerig <michael@...> [2008-06-10 15:55]:
      > >> > I'm looking for a way to have my cake and eat it: pretty and
      > >> > public URLs, no cookies or javascript required, and sessions
      > >> > nevertheless.
      > >>
      > >> I think you should start by questioning whether you need sessions
      > >> in the first place. What data are you storing in them and why
      > >> does that data not deserve to be a named first class resource?
      > >
      > > When I have a *user* interface where some resources need
      > > authenticated access, then I need some kind of session, don't I?
      >
      > Not necessarily.
      >
      > If you want to be purely RESTful, you'd strive to use HTTP
      > authentication for such things, but practically that's tough. Often,
      > frameworks/tools use a cookie to represent a transient auth token.
      [snip]
      > So, what data are you storing in the sessions? Why?

      Authentication information is usually enough.

      Michael

      --
      Michael Schuerig
      mailto:michael@...
      http://www.schuerig.de/michael/
    • Michael Schuerig
      ... Most respondents have apparently understood session as meaning server-side conversational state. That s not what I had in mind, I m quite content with
      Message 2 of 28 , Jun 10, 2008
      • 0 Attachment
        On Wednesday 11 June 2008, Etan Wexler wrote:
        > Michael Schuerig wrote (in
        >
        > <http://tech.groups.yahoo.com/group/rest-discuss/message/10894>):
        > > When I have a *user* interface where some resources need
        > > authenticated access, then I need some kind of session, don't I?
        >
        > When you have a user interface in which access to some resources
        > requires authentication (and, presumably, authorization), there is no
        > need for maintaining a session at the origin server.

        Most respondents have apparently understood "session" as meaning
        server-side conversational state. That's not what I had in mind, I'm
        quite content with authentication information or possibly a set of
        capabilities.

        > As the
        > administrator of the origin server, all that you need is that each
        > request bear acceptable credentials. Even that is not quite correct,
        > because a request that fails to bear acceptable credentials should
        > prompt a response that bears a challenge for credentials. Did I miss
        > something?

        Possibly. Let's say I have a resource where the representation depends
        on the credentials of the requester. I could associate each
        representation with its own URL, but that's not what I want.
        Essentially, I only ever want to have one canonical URL and a requester
        gets to see what their credentials allow. In particular, someone with
        no credentials at all may still get to see a rudimentary
        representation. In such a scenario there is no point in challenging the
        requester -- human user. They may decide to log in or log in with
        different credentials, but that's up to the them.

        Also, as far as I can tell, an http auth challenge involves popping up a
        browser-level dialog. I take it, most users aren't accustomed to this.
        And, at any rate, it modally drags them out of the application context
        without a chance for inline help messages or "I forgot my password"
        links.

        I'd really like to make this work, but I'm not convinced there is a way.

        Michael

        --
        Michael Schuerig
        mailto:michael@...
        http://www.schuerig.de/michael/
      • Bruno Harbulot
        Hello, ... I agree entirely. Although I d also prefer authentication mechanisms based on WWW-Authenticate (and related headers), sometimes, it s practically
        Message 3 of 28 , Jun 10, 2008
        • 0 Attachment
          Hello,

          Josh Sled wrote:
          > Michael Schuerig <michael@...> writes:
          >> On Wednesday 11 June 2008, Aristotle Pagaltzis wrote:
          >>> * Michael Schuerig <michael@...> [2008-06-10 15:55]:
          >>>> I'm looking for a way to have my cake and eat it: pretty and
          >>>> public URLs, no cookies or javascript required, and sessions
          >>>> nevertheless.
          >>> I think you should start by questioning whether you need sessions
          >>> in the first place. What data are you storing in them and why
          >>> does that data not deserve to be a named first class resource?
          >> When I have a *user* interface where some resources need authenticated
          >> access, then I need some kind of session, don't I?
          >
          > Not necessarily.
          >
          > If you want to be purely RESTful, you'd strive to use HTTP authentication for
          > such things, but practically that's tough. Often, frameworks/tools use a
          > cookie to represent a transient auth token.
          >
          > But even the latter is slightly different from having a stateful session.
          > The general use-case of a session is the server-side software keeping an
          > object "around" in the user's session such that some subsequent request's
          > handling can get at that object without needing to "carry" it through the
          > intervening pages/requests.
          >
          > It is *that* session state that REST eschews.

          I agree entirely. Although I'd also prefer authentication mechanisms
          based on WWW-Authenticate (and related headers), sometimes, it's
          practically impossible, hence the use of a cookie to maintain an
          authenticated session (using a cookie being by far better than using a
          session id in a URI parameter).

          I think this doesn't contradict the stateless interactions principle of
          REST, as long as the session is only used for authentication purposes.
          In my opinion, authentication should be considered as orthogonal to the
          function of the application.
          In fact, I think most secure authentication mechanisms maintain some
          form of state during a set of interactions with the client. If that's of
          interest, I tried to make a list of HTTP authentication mechanisms a
          couple of days ago, looking at this with Restlet in mind (*).

          Best wishes,

          Bruno.


          (*)
          http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet
        • Peter Keane
          Michael- I ve had good luck with a two-step page load: the html page is rendered regardless of identity/authorization and is identical for all users (and is
          Message 4 of 28 , Jun 10, 2008
          • 0 Attachment
            Michael-

            I've had good luck with a two-step page load: the html page is rendered
            regardless of identity/authorization and is identical for all users (and
            is thus cache-able). There *is* an identity cookie on the client (how
            it got there is a longer explanation, not entirely REST-copacetic, but
            as close as I could get). Once the page loads, javascript make a second
            XHR request which "customizes" the page (dom insertions that include
            hypertext links to other resources only this user can get at). The url
            for that second request *does* include the username, meaning it is a
            resource unique to this user. I do authenticate that second request w/
            the secure identity token in the cookie (again, not so REST). There
            is no application state on the server. The code ends up being nicely
            organized as a set of resources easily manageable w/ a simple framework.
            There's more to it (AtomPub & JSONRest interfaces) but you get the idea.
            Obviously, not a universally acceptable solution (requires javascript,
            uses cookies, etc.) but works well in my case.

            --peter keane
            http://dase.googlecode.com

            On Wed, Jun 11, 2008 at 02:58:14AM +0200, Michael Schuerig wrote:
            > On Wednesday 11 June 2008, Etan Wexler wrote:
            > > Michael Schuerig wrote (in
            > >
            > > <[1]http://tech.groups.yahoo.com/group/rest-discuss/message/10894>):
            > > > When I have a *user* interface where some resources need
            > > > authenticated access, then I need some kind of session, don't I?
            > >
            > > When you have a user interface in which access to some resources
            > > requires authentication (and, presumably, authorization), there is no
            > > need for maintaining a session at the origin server.
            > Most respondents have apparently understood "session" as meaning
            > server-side conversational state. That's not what I had in mind, I'm
            > quite content with authentication information or possibly a set of
            > capabilities.
            > > As the
            > > administrator of the origin server, all that you need is that each
            > > request bear acceptable credentials. Even that is not quite correct,
            > > because a request that fails to bear acceptable credentials should
            > > prompt a response that bears a challenge for credentials. Did I miss
            > > something?
            > Possibly. Let's say I have a resource where the representation depends
            > on the credentials of the requester. I could associate each
            > representation with its own URL, but that's not what I want.
            > Essentially, I only ever want to have one canonical URL and a requester
            > gets to see what their credentials allow. In particular, someone with
            > no credentials at all may still get to see a rudimentary
            > representation. In such a scenario there is no point in challenging the
            > requester -- human user. They may decide to log in or log in with
            > different credentials, but that's up to the them.
            > Also, as far as I can tell, an http auth challenge involves popping up
            > a
            > browser-level dialog. I take it, most users aren't accustomed to this.
            > And, at any rate, it modally drags them out of the application context
            > without a chance for inline help messages or "I forgot my password"
            > links.
            > I'd really like to make this work, but I'm not convinced there is a
            > way.
            > Michael
            > --
            > Michael Schuerig
            > mailto:[2]michael@...
            > [3]http://www.schuerig.de/michael/
            >
          • mike amundsen
            Michael: Some comments on the HTTP Auth issue: First, HTTP Auth is your best (safest, easiest, most portable) way to identify your users. This is especially
            Message 5 of 28 , Jun 10, 2008
            • 0 Attachment
              Michael:

              Some comments on the HTTP Auth issue:
              First, HTTP Auth is your best (safest, easiest, most portable) way to
              identify your users. This is especially true when you start supporting
              non-human interaction with your applications. While the dialogs
              offered by common browsers are disappointing, they are what they are.

              Second, I found that I *want* authentication to be 'out-of-band.' I
              don't want to write code in my application to present these dialogs,
              accept, validate, and process the inputs. I just want the
              authentication to be done and the results handed off to me. I also do
              not want to 'carry' lots of (possibly dangerous) metadata around or
              store it in disk or memory on the server. HTTP Auth handles all this
              quite nicely.

              Thrid, there are a number of 'work-arounds' to the browser dialog if
              you really want to try to hide this. Paul James has posted some fine
              material on the subject. There are others, too.

              Now about the the URLs:
              I've come to think that URLs are cheap and you can mint lots of them.
              I see no reason to *not* present users w/ 'personalized' URLs
              (/recent-updates/mike/). That doesn't mean you need to always pass
              these personalized URIs to the client. For example, a call to
              /recent-updates/ might get the server to check the credentials and
              then forward the request to the 'personalized' URL. If the client has
              not authenticated, then the server will not forward to the custom URL
              and just present the 'public' document that lives at /recent-updates/
              (which might include a link to login).

              Another reason to consider URLs that include identifying data is that
              they are rather easy to secure. For example, if your personalized URLs
              all contain ../users/<user-id>/.. you can write server code that
              validates the requested URL against the login credentails and rejects
              improperly authenticated requests.

              Caching comes into play, too. If you present a document from /my-data/
              that has been built up on the server using metadata (user id,
              session-id, etc.), it's possible that some server will cache that
              page. If another user comes along (an un-authed user) and requests the
              same URL, they might get the wrong data. Of course, you can mark all
              your content as non-cacheable, but is that what you want?

              Just some things to consider.

              MikeA

              On Tue, Jun 10, 2008 at 8:58 PM, Michael Schuerig <michael@...> wrote:
              > On Wednesday 11 June 2008, Etan Wexler wrote:
              >> Michael Schuerig wrote (in
              >>
              >> <http://tech.groups.yahoo.com/group/rest-discuss/message/10894>):
              >> > When I have a *user* interface where some resources need
              >> > authenticated access, then I need some kind of session, don't I?
              >>
              >> When you have a user interface in which access to some resources
              >> requires authentication (and, presumably, authorization), there is no
              >> need for maintaining a session at the origin server.
              >
              > Most respondents have apparently understood "session" as meaning
              > server-side conversational state. That's not what I had in mind, I'm
              > quite content with authentication information or possibly a set of
              > capabilities.
              >
              >> As the
              >> administrator of the origin server, all that you need is that each
              >> request bear acceptable credentials. Even that is not quite correct,
              >> because a request that fails to bear acceptable credentials should
              >> prompt a response that bears a challenge for credentials. Did I miss
              >> something?
              >
              > Possibly. Let's say I have a resource where the representation depends
              > on the credentials of the requester. I could associate each
              > representation with its own URL, but that's not what I want.
              > Essentially, I only ever want to have one canonical URL and a requester
              > gets to see what their credentials allow. In particular, someone with
              > no credentials at all may still get to see a rudimentary
              > representation. In such a scenario there is no point in challenging the
              > requester -- human user. They may decide to log in or log in with
              > different credentials, but that's up to the them.
              >
              > Also, as far as I can tell, an http auth challenge involves popping up a
              > browser-level dialog. I take it, most users aren't accustomed to this.
              > And, at any rate, it modally drags them out of the application context
              > without a chance for inline help messages or "I forgot my password"
              > links.
              >
              > I'd really like to make this work, but I'm not convinced there is a way.
              >
              > Michael
              >
              > --
              > Michael Schuerig
              > mailto:michael@...
              > http://www.schuerig.de/michael/
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
              >



              --
              mca
              http://amundsen.com/blog/
            • Etan Wexler
              Michael Schuerig wrote (in ... Identification of resources is fundamental to the Representational State Transfer. I favor promoting representations to
              Message 6 of 28 , Jun 10, 2008
              • 0 Attachment
                Michael Schuerig wrote (in
                <http://tech.groups.yahoo.com/group/rest-discuss/message/10901>):

                > Let's say I have a resource where the representation depends
                > on the credentials of the requester. I could associate each
                > representation with its own URL, but that's not what I want.

                Identification of resources is fundamental to the Representational State
                Transfer. I favor promoting representations to resources in their own
                right, because doing so facilitates discussion, nuanced linking, and
                manipulation.

                > Essentially, I only ever want to have one canonical URL and a requester
                > gets to see what their credentials allow.

                So, in HTTP, send a response with a "Vary" header-field that indicates
                that responses vary depending on credentials.

                > In particular, someone with
                > no credentials at all may still get to see a rudimentary
                > representation. In such a scenario there is no point in challenging the
                > requester -- human user. They may decide to log in or log in with
                > different credentials, but that's up to the them.

                So, in HTTP, send a response with a status-code of "200" and still send
                the challenge.

                > Also, as far as I can tell, an http auth challenge involves popping up a
                > browser-level dialog. I take it [that] most users aren't accustomed to this.
                > And, at any rate, it modally drags them out of the application context
                > without a chance for inline help messages or "I forgot my password"
                > links.

                While the scene on the ground is rough and shabby, there is nothing in
                the HTTP specifications or in REST that mandates a lousy presentation of
                authentication challenges. Clever people have found graceful ways of
                using HTTP authentication challenges and HTTP authentication that work
                even in the current crop of disgraceful implementations. Still, it would
                be great to have user agents that present authentication challenges
                along with and at the same time as entity-bodies.

                Dear LazyWeb,

                Make for me a Web browser that includes an informational banner where I
                can easily evaluate and meet authentication challenges. I want clear
                indications of the authority issuing the challenge, the IRI of the
                resource in question, the authentication scheme, the security of the
                authentication scheme, and the status of the response as a whole.

                --
                Please do not reply to me when replying to rest-discuss. I read the
                messages that people send to rest-discuss and I do not want duplicates.
              • Aristotle Pagaltzis
                ... Then you don’t need to store anything on the server. There is no need for a session at all. Either use HTTP Auth or, in case you are talking to a
                Message 7 of 28 , Jun 10, 2008
                • 0 Attachment
                  * Michael Schuerig <michael@...> [2008-06-11 02:30]:
                  > Authentication information is usually enough.

                  Then you don’t need to store anything on the server. There is no
                  need for a session at all. Either use HTTP Auth or, in case you
                  are talking to a browser, use a cookie like this:

                  auth_token = concat( username, ":", expiration_datetime );
                  msghash = digest_hmac( concat( server_secret, ":", auth_token ) );
                  cookie = concat( msghash, ":", auth_token );

                  With this scheme, cookies cannot be forged because generating
                  a correct message hash requires knowledge of the server secret
                  that is not part of the cookie. So if the client sends you a
                  cookie whose hash checks out, you know it’s a cookie you minted
                  and you can therefore trust the username portion of the cookie.
                  Aside from the server secret, which is easily kept in memory,
                  you don’t need any information external to the cookie in order
                  to verify it: no on-disk session.


                  * Bruno Harbulot <Bruno.Harbulot@...> [2008-06-11 04:45]:
                  > I think this doesn't contradict the stateless interactions
                  > principle of REST, as long as the session is only used for
                  > authentication purposes.

                  Indeed it doesn’t.

                  Regards,
                  --
                  Aristotle Pagaltzis // <http://plasmasturm.org/>
                • Michael Schuerig
                  ... That s an interesting approach. I wouldn t object to private URLs in this case, but there s still the cookie. Michael -- Michael Schuerig
                  Message 8 of 28 , Jun 11, 2008
                  • 0 Attachment
                    On Wednesday 11 June 2008, Peter Keane wrote:

                    > I've had good luck with a two-step page load: the html page is
                    > rendered regardless of identity/authorization and is identical for
                    > all users (and is thus cache-able). There *is* an identity cookie on
                    > the client (how it got there is a longer explanation, not entirely
                    > REST-copacetic, but as close as I could get). Once the page loads,
                    > javascript make a second XHR request which "customizes" the page (dom
                    > insertions that include hypertext links to other resources only this
                    > user can get at).

                    That's an interesting approach. I wouldn't object to "private" URLs in
                    this case, but there's still the cookie.

                    Michael

                    --
                    Michael Schuerig
                    mailto:michael@...
                    http://www.schuerig.de/michael/
                  • Michael Schuerig
                    ... I don t want to use a cookie, that s more or less the whole point of my original message. I know how to get what I want with a cookie, my question is,
                    Message 9 of 28 , Jun 11, 2008
                    • 0 Attachment
                      On Wednesday 11 June 2008, Aristotle Pagaltzis wrote:
                      > > Authentication information is usually enough.
                      >
                      > Then you don’t need to store anything on the server. There is no
                      > need for a session at all. Either use HTTP Auth or, in case you
                      > are talking to a browser, use a cookie like this:

                      I don't want to use a cookie, that's more or less the whole point of my
                      original message. I know how to get what I want with a cookie, my
                      question is, whether I can get the same result without a cookie.

                      Michael

                      --
                      Michael Schuerig
                      mailto:michael@...
                      http://www.schuerig.de/michael/
                    • Michael Schuerig
                      ... Unfortunately, because they are what they are, they are not acceptable. I see your point regarding non-human interaction, but that s a different issue. ...
                      Message 10 of 28 , Jun 11, 2008
                      • 0 Attachment
                        On Wednesday 11 June 2008, mike amundsen wrote:
                        > Michael:
                        >
                        > Some comments on the HTTP Auth issue:
                        > First, HTTP Auth is your best (safest, easiest, most portable) way to
                        > identify your users. This is especially true when you start
                        > supporting non-human interaction with your applications. While the
                        > dialogs offered by common browsers are disappointing, they are what
                        > they are.

                        Unfortunately, because they are what they are, they are not acceptable.
                        I see your point regarding non-human interaction, but that's a
                        different issue.

                        > Second, I found that I *want* authentication to be 'out-of-band.' I
                        > don't want to write code in my application to present these dialogs,
                        > accept, validate, and process the inputs. I just want the
                        > authentication to be done and the results handed off to me. I also
                        > do not want to 'carry' lots of (possibly dangerous) metadata around
                        > or store it in disk or memory on the server. HTTP Auth handles all
                        > this quite nicely.

                        I agree with the general point, but the practical problem really is how
                        the HTTP Auth header gets populated, i.e., the out-of-band dialog. Just
                        imagine any major site switching to this kind of authentication dialog.
                        I wouldn't expect users to be pleased.

                        > Thrid, there are a number of 'work-arounds' to the browser dialog if
                        > you really want to try to hide this. Paul James has posted some fine
                        > material on the subject. There are others, too.

                        I've skimmed some of <http://www.peej.co.uk/> and tried
                        <http://www.peej.co.uk/articles/http-auth-with-html-forms.html>. It
                        didn't work in my browser (Konqueror).

                        > Now about the the URLs:
                        > I've come to think that URLs are cheap and you can mint lots of them.
                        > I see no reason to *not* present users w/ 'personalized' URLs
                        > (/recent-updates/mike/). That doesn't mean you need to always pass
                        > these personalized URIs to the client. For example, a call to
                        > /recent-updates/ might get the server to check the credentials and
                        > then forward the request to the 'personalized' URL. If the client has
                        > not authenticated, then the server will not forward to the custom URL
                        > and just present the 'public' document that lives at /recent-updates/
                        > (which might include a link to login).
                        >
                        > Another reason to consider URLs that include identifying data is that
                        > they are rather easy to secure. For example, if your personalized
                        > URLs all contain ../users/<user-id>/.. you can write server code that
                        > validates the requested URL against the login credentails and rejects
                        > improperly authenticated requests.

                        I really want to avoid personalized URLs. Most of all, because users
                        pass URLs to other users. As you say, a personalized URL can be secured
                        nonetheless, but the effect is that the receiver can't really get at
                        the resource they were pointed to. Better to give them a URL that they
                        can retrieve.

                        > Caching comes into play, too. If you present a document from
                        > /my-data/ that has been built up on the server using metadata (user
                        > id, session-id, etc.), it's possible that some server will cache that
                        > page. If another user comes along (an un-authed user) and requests
                        > the same URL, they might get the wrong data. Of course, you can mark
                        > all your content as non-cacheable, but is that what you want?

                        Yes, I think making authorized content non-cacheable is what I want.


                        I'd like to point out that I appreciate all the replies I've received.
                        My fussyness about the proposed solutions is mainly due to the fact
                        that I'm already quite happy with my current approach using cookies.
                        It's just that I'd like to make that further step of getting rid of the
                        cookies.

                        Michael

                        --
                        Michael Schuerig
                        mailto:michael@...
                        http://www.schuerig.de/michael/
                      • Michael Schuerig
                        ... I agree when it comes to non-human requesters, for human beings I m not convinced. ... Agreed, but that is the state of things, and to my mind it is a
                        Message 11 of 28 , Jun 11, 2008
                        • 0 Attachment
                          On Wednesday 11 June 2008, Etan Wexler wrote:
                          > Michael Schuerig wrote (in
                          >
                          > <http://tech.groups.yahoo.com/group/rest-discuss/message/10901>):
                          > > Let's say I have a resource where the representation depends
                          > > on the credentials of the requester. I could associate each
                          > > representation with its own URL, but that's not what I want.
                          >
                          > Identification of resources is fundamental to the Representational
                          > State Transfer. I favor promoting representations to resources in
                          > their own right, because doing so facilitates discussion, nuanced
                          > linking, and manipulation.

                          I agree when it comes to non-human requesters, for human beings I'm not
                          convinced.

                          > > Also, as far as I can tell, an http auth challenge involves popping
                          > > up a browser-level dialog. I take it [that] most users aren't
                          > > accustomed to this. And, at any rate, it modally drags them out of
                          > > the application context without a chance for inline help messages
                          > > or "I forgot my password" links.
                          >
                          > While the scene on the ground is rough and shabby, there is nothing
                          > in the HTTP specifications or in REST that mandates a lousy
                          > presentation of authentication challenges.

                          Agreed, but that is the state of things, and to my mind it is a
                          show-stopper.

                          Michael

                          --
                          Michael Schuerig
                          mailto:michael@...
                          http://www.schuerig.de/michael/
                        • Stefan Tilkov
                          ... As you point out, the only problem with cookies used in a RESTful way (i.e. not identifying server-side conversation state) is that you can t have two
                          Message 12 of 28 , Jun 11, 2008
                          • 0 Attachment
                            On Jun 11, 2008, at 10:01 AM, Michael Schuerig wrote:

                            It's just that I'd like to make that further step of getting rid of the 
                            cookies.

                            As you point out, the only problem with cookies used in a RESTful way (i.e. not identifying server-side conversation state) is that you can't have two browser sessions with different credentials. Maybe you could require the subset of users who are interested in actually doing this with the HTTP Auth alternative, using a common backend?

                            If you offer protected syndication feeds or some other form of Web API, you need something other than cookies anyway. It seems to boil down to a usable UI design.

                            Stefan
                          • Michael Schuerig
                            ... Another issue is that some users don t want (allow, trust) cookies. I can t tell how much of a problem this really is, but I know that I get annoyed when I
                            Message 13 of 28 , Jun 11, 2008
                            • 0 Attachment
                              On Wednesday 11 June 2008, Stefan Tilkov wrote:
                              > On Jun 11, 2008, at 10:01 AM, Michael Schuerig wrote:
                              > > It's just that I'd like to make that further step of getting rid of
                              > > the cookies.
                              >
                              > As you point out, the only problem with cookies used in a RESTful way
                              > (i.e. not identifying server-side conversation state) is that you
                              > can't have two browser sessions with different credentials.

                              Another issue is that some users don't want (allow, trust) cookies. I
                              can't tell how much of a problem this really is, but I know that I get
                              annoyed when I notice that a site is throwing lots of cookies at me.

                              > Maybe you
                              > could require the subset of users who are interested in actually
                              > doing this with the HTTP Auth alternative, using a common backend?

                              I don't think that'd be worth the trouble.

                              > If you offer protected syndication feeds or some other form of Web
                              > API, you need something other than cookies anyway. It seems to boil
                              > down to a usable UI design.

                              Yes.

                              Michael

                              --
                              Michael Schuerig
                              mailto:michael@...
                              http://www.schuerig.de/michael/
                            • Bruno Harbulot
                              ... As far as I know, most browsers also effectively perform single-sign on of a single user (for that realm) across tabs and windows with HTTP authentication.
                              Message 14 of 28 , Jun 11, 2008
                              • 0 Attachment
                                Stefan Tilkov wrote:
                                >
                                >
                                > On Jun 11, 2008, at 10:01 AM, Michael Schuerig wrote:
                                >
                                >> It's just that I'd like to make that further step of getting rid of the
                                >> cookies.
                                >
                                > As you point out, the only problem with cookies used in a RESTful way
                                > (i.e. not identifying server-side conversation state) is that you can't
                                > have two browser sessions with different credentials. Maybe you could
                                > require the subset of users who are interested in actually doing this
                                > with the HTTP Auth alternative, using a common backend?

                                As far as I know, most browsers also effectively perform single-sign on
                                of a single user (for that realm) across tabs and windows with HTTP
                                authentication. Moving from cookies to HTTP Auth wouldn't help in that
                                respect.

                                Best wishes,

                                Bruno.
                              • Bruno Harbulot
                                ... It does matter, even for human users: think of it as bookmarkable URLs. Have you ever been on a shopping website, looked at a product, found it
                                Message 15 of 28 , Jun 11, 2008
                                • 0 Attachment
                                  Michael Schuerig wrote:
                                  >
                                  >
                                  > On Wednesday 11 June 2008, Etan Wexler wrote:
                                  > > Michael Schuerig wrote (in
                                  > >
                                  > > <http://tech.groups.yahoo.com/group/rest-discuss/message/10901
                                  > <http://tech.groups.yahoo.com/group/rest-discuss/message/10901>>):
                                  > > > Let's say I have a resource where the representation depends
                                  > > > on the credentials of the requester. I could associate each
                                  > > > representation with its own URL, but that's not what I want.
                                  > >
                                  > > Identification of resources is fundamental to the Representational
                                  > > State Transfer. I favor promoting representations to resources in
                                  > > their own right, because doing so facilitates discussion, nuanced
                                  > > linking, and manipulation.
                                  >
                                  > I agree when it comes to non-human requesters, for human beings I'm not
                                  > convinced.

                                  It does matter, even for human users: think of it as "bookmarkable"
                                  URLs. Have you ever been on a shopping website, looked at a product,
                                  found it interesting, bookmarked it for later use, come back the day
                                  after and been told "your session has expired, go back to the main
                                  page"? That's not great for the user.

                                  Best wishes,

                                  Bruno.
                                • Bruno Harbulot
                                  ... I m not sure why you re so against cookies. They usually conflict with the stateless interactions principle, but in this case you have little choice. ...
                                  Message 16 of 28 , Jun 11, 2008
                                  • 0 Attachment
                                    Michael Schuerig wrote:
                                    >
                                    >
                                    > On Wednesday 11 June 2008, Aristotle Pagaltzis wrote:
                                    > > > Authentication information is usually enough.
                                    > >
                                    > > Then you don’t need to store anything on the server. There is no
                                    > > need for a session at all. Either use HTTP Auth or, in case you
                                    > > are talking to a browser, use a cookie like this:
                                    >
                                    > I don't want to use a cookie, that's more or less the whole point of my
                                    > original message. I know how to get what I want with a cookie, my
                                    > question is, whether I can get the same result without a cookie.

                                    I'm not sure why you're so against cookies. They usually conflict with
                                    the stateless interactions principle, but in this case you have little
                                    choice.


                                    To quote your original message:
                                    > I'm looking for a way to have my cake and eat it: pretty and public
                                    > URLs, no cookies or javascript required, and sessions nevertheless.

                                    I'm assuming, with all this, that you want it to work from most major
                                    browsers, without any plugin.


                                    Obviously, authentication requires that you be able to send some
                                    information as part of your request.

                                    As it's been said before, you get 3 ways to do it: in the URI, in HTTP
                                    Auth or in a cookie.

                                    1. As part of the URI.

                                    You could in principle send representations that contain URI specially
                                    crafted for the authenticated user (using a token in the query for
                                    example). Somehow, this would probably be the most RESTful but have a
                                    number of downsides and change the meaning of your application. You
                                    would no longer interact with resource "X" identified by URI "http://x",
                                    but with resource "X when authenticated using A" identified by URI
                                    "http://x?auth=a" (or some other way to put 'a' in the URI). There's a
                                    number of downsides with that, mainly because you would have to make
                                    these URIs (with an authentication token) short-lived to enforce some
                                    sort of security (which would be limited anyway). What you could do,
                                    however, is to change the state of resource "http://x?auth=a" when the
                                    user authentication token has expired so that its returns a
                                    representation it returns a representation that invites the user to log in.
                                    This wouldn't be my favourite solution, since it is likely to imply so
                                    tangling of the application code with the authentication code on the
                                    server and also make the representations the client obtains only usable
                                    for a limited amount of time.


                                    2. Using HTTP authentication (WWW-Authenticate/Authorization headers).

                                    This would be the cleanest way. Unfortunately, you don't seem to want it
                                    because you don't like the dialog box that would appear. I'm yet to find
                                    any user critically injured by such a box, but there are reasons indeed
                                    for not wanting them:
                                    - corporate identity and style of the web-site: this could potentially
                                    be overcome by leading your user to the protected pages via a
                                    non-protected page that would have the pretty background and logos you
                                    want and that would say: "you're going to be prompted for your
                                    password". It's really cosmetic, but it may matter.
                                    - offering the user the possibility to reset their password: nothing
                                    prevents you from putting a link to such a page in the representation
                                    returned with a "401 Unauthorized" or "403 Forbidden" if they've
                                    cancelled the dialog box or used a wrong password.

                                    You could also use something like SPNEGO instead of Basic/Digest
                                    authentication, but that requires some control over the environment in
                                    which the browser runs, to set up Kerberos/Active Directory.

                                    As far as I know, these are the only mechanisms that are supported
                                    across a wide range of browsers. There are other HTTP Auth mechanisms,
                                    unfortunately, they're unlikely to be supported out of the box by most
                                    browsers. You could potentially emulate them via Ajax tricks, but you
                                    said you didn't want any JavaScript.


                                    3. Using a cookie.

                                    The only way most browsers support the addition of custom metadata
                                    (authentication is metadata, whether using HTTP Auth or cookie or
                                    another header) is via cookies. You seem to say from another message
                                    that the main reason against it is that users don't want to allow cookies.

                                    I'm a bit lost on that last point, and how it seems to conflict with not
                                    using dialog authentication boxes:
                                    a) If your users insist on the prettiness/corporate identity of the
                                    website to have authentication forms because that's what everyone does
                                    and it looks trendy, that's fair enough. However, users who are used to
                                    this certainly allow cookies on a regular basis (knowingly or not).
                                    b) If your users have been taught how to deal with cookies (perhaps
                                    not appropriately, cookies are not necessarily "evil"), surely they'll
                                    be able to understand how a Basic/Digest authentication dialog box works.


                                    Another way, which is supported by most browsers, would be to use
                                    client-side certificates for SSL authentication. This works well, but
                                    deploying a PKI is not trivial and also requires to train users to
                                    handle their private keys and certificates with appropriate care.



                                    I'd use cookies in the short term and try to lobby browser vendors and
                                    talk with organisations like IETF to support other HTTP authentication
                                    schemes (perhaps something like "WWW-Authenticate: Form ...") in the
                                    long term, if you have some spare time...


                                    Best wishes,

                                    Bruno.
                                  • Michael Schuerig
                                    ... Bruno, thanks for your extensive reply. I m not a fervent opponent of cookies and JavaScript, indeed, I m happily using both of them. The reason for my
                                    Message 17 of 28 , Jun 11, 2008
                                    • 0 Attachment
                                      On Wednesday 11 June 2008, Bruno Harbulot wrote:
                                      > I'd use cookies in the short term and try to lobby browser vendors
                                      > and talk with organisations like IETF to support other HTTP
                                      > authentication schemes (perhaps something like "WWW-Authenticate:
                                      > Form ...") in the long term, if you have some spare time...

                                      Bruno, thanks for your extensive reply. I'm not a fervent opponent of
                                      cookies and JavaScript, indeed, I'm happily using both of them. The
                                      reason for my original question was not that I have an urgent, very
                                      complicated problem. It's rather that I already have a working
                                      solution, but if possible would like to improve it in some ways. Where
                                      my idea of what constitutes an improvement isn't shared by everyone.
                                      Furthermore, that explains why I may react somewhat obstinate to the
                                      proposed solutions: I already have the cake and now I'm being choosey
                                      when it comes to decide what icing would be the nicest.

                                      Michael

                                      --
                                      Michael Schuerig
                                      mailto:michael@...
                                      http://www.schuerig.de/michael/
                                    • Aristotle Pagaltzis
                                      ... Ah, I sort of missed that part. How could you possibly do that? The auth information has to be *some*where – either in the URI, or in headers, or in the
                                      Message 18 of 28 , Jun 11, 2008
                                      • 0 Attachment
                                        * Michael Schuerig <michael@...> [2008-06-11 09:40]:
                                        > I don't want to use a cookie, that's more or less the whole
                                        > point of my original message. I know how to get what I want
                                        > with a cookie, my question is, whether I can get the same
                                        > result without a cookie.

                                        Ah, I sort of missed that part. How could you possibly do that?
                                        The auth information has to be *some*where – either in the URI,
                                        or in headers, or in the request body. There is no other place
                                        to put it.

                                        “In the body” is out, because that means using POST as GET.

                                        “In the header” means you have to do HTTP Auth or cookies.

                                        “In the URI” means you have to do personalised URIs.

                                        Regards,
                                        --
                                        Aristotle Pagaltzis // <http://plasmasturm.org/>
                                      • Aristotle Pagaltzis
                                        ... Then instead of sending 403 with a login page in the body, send 303 with the non-personalised URI in Location. Don’t forget to Vary on whatever header
                                        Message 19 of 28 , Jun 11, 2008
                                        • 0 Attachment
                                          * Michael Schuerig <michael@...> [2008-06-11 10:05]:
                                          > I really want to avoid personalized URLs. Most of all, because
                                          > users pass URLs to other users. As you say, a personalized URL
                                          > can be secured nonetheless, but the effect is that the receiver
                                          > can't really get at the resource they were pointed to. Better
                                          > to give them a URL that they can retrieve.

                                          Then instead of sending 403 with a login page in the body, send
                                          303 with the non-personalised URI in Location. Don’t forget to
                                          Vary on whatever header you use for your auth token, be it a
                                          cookie or HTTP Auth.

                                          Regards,
                                          --
                                          Aristotle Pagaltzis // <http://plasmasturm.org/>
                                        • Xavier Noria
                                          ... Something similar to this is what Rails does by default since version 2.
                                          Message 20 of 28 , Jun 11, 2008
                                          • 0 Attachment
                                            On Wed, Jun 11, 2008 at 8:26 AM, Aristotle Pagaltzis <pagaltzis@...> wrote:

                                            > Then you don't need to store anything on the server. There is no
                                            > need for a session at all. Either use HTTP Auth or, in case you
                                            > are talking to a browser, use a cookie like this:
                                            >
                                            > auth_token = concat( username, ":", expiration_datetime );
                                            > msghash = digest_hmac( concat( server_secret, ":", auth_token ) );
                                            > cookie = concat( msghash, ":", auth_token );

                                            Something similar to this is what Rails does by default since version 2.
                                          • Peter Keane
                                            ... I spent quite a lot of time on this issue a few months back, determined to not use cookies. I implemented an http basic auth solutionfor parts of the api,
                                            Message 21 of 28 , Jun 11, 2008
                                            • 0 Attachment
                                              On Wed, Jun 11, 2008 at 10:50:49PM +0200, Xavier Noria wrote:
                                              > On Wed, Jun 11, 2008 at 8:26 AM, Aristotle Pagaltzis <[1]pagaltzis@gmx.
                                              > de> wrote:
                                              > > Then you don't need to store anything on the server. There is no
                                              > > need for a session at all. Either use HTTP Auth or, in case you
                                              > > are talking to a browser, use a cookie like this:
                                              > >
                                              > > auth_token = concat( username, ":", expiration_datetime );
                                              > > msghash = digest_hmac( concat( server_secret, ":", auth_token ) );
                                              > > cookie = concat( msghash, ":", auth_token );
                                              > Something similar to this is what Rails does by default since version
                                              > 2.

                                              I spent quite a lot of time on this issue a few months back, determined to not use cookies. I implemented an http basic auth solutionfor parts of the api, but ultimately settled on the solution Aristotle describes for interaction w/ browsers. As far as I am concerned, this is the current best practice for RESTful authentication. This <user_id:expiration:hash> cookie was by far the cleanest for the "browser facing" parts as compared to other mechanisms.

                                              Note that it is always ONLY used for a thumbs-up or thumbs-down for requests that require authentication (not all do). It in no way ties into server state not addressed in the url.

                                              --peter keane

                                              >
                                              >
                                              > References
                                              >
                                              > 1. mailto:pagaltzis%40gmx.de
                                              > 2. http://groups.yahoo.com/group/rest-discuss/message/10886;_ylc=X3oDMTM2NW1uaHBwBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzEwOTI3BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTIxMzIxNzQ1MQR0cGNJZAMxMDg4Ng--
                                              > 3. http://groups.yahoo.com/group/rest-discuss/post;_ylc=X3oDMTJxZ2E5aDE5BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzEwOTI3BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTIxMzIxNzQ1MQ--?act=reply&messageNum=10927
                                              > 4. http://groups.yahoo.com/group/rest-discuss/post;_ylc=X3oDMTJlcGRlOWluBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTIxMzIxNzQ1MQ--
                                              > 5. http://groups.yahoo.com/group/rest-discuss/messages;_ylc=X3oDMTJlMzQ3ajVoBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA21zZ3MEc3RpbWUDMTIxMzIxNzQ1MQ--
                                              > 6. http://groups.yahoo.com/group/rest-discuss/members;_ylc=X3oDMTJlOGQ4azFpBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA21icnMEc3RpbWUDMTIxMzIxNzQ1MQ--
                                              > 7. http://us.ard.yahoo.com/SIG=13rmher3p/M=624381.12730922.13032918.10835568/D=groups/S=1705701014:MKP1/Y=YAHOO/EXP=1213224651/L=/B=GEhoBELaX9E-/J=1213217451885490/A=5379723/R=0/SIG=14evd63no/*http://media.adrevolver.com/adrevolver/href?banner=189158&place=26143&url_=http://tc.deals.yahoo.com/tc/blockbuster/display.com?cid=bbi00027
                                              > 8. http://us.ard.yahoo.com/SIG=13rmher3p/M=624381.12730922.13032918.10835568/D=groups/S=1705701014:MKP1/Y=YAHOO/EXP=1213224651/L=/B=GEhoBELaX9E-/J=1213217451885490/A=5379723/R=1/SIG=14evd63no/*http://media.adrevolver.com/adrevolver/href?banner=189158&place=26143&url_=http://tc.deals.yahoo.com/tc/blockbuster/display.com?cid=bbi00027
                                              > 9. http://groups.yahoo.com/;_ylc=X3oDMTJkN3A2YTdhBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMjEzMjE3NDUx
                                              > 10. http://groups.yahoo.com/group/rest-discuss/join;_ylc=X3oDMTJmdWhoZGo2BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyMTMyMTc0NTE-
                                              > 11. mailto:rest-discuss-digest@yahoogroups.com?subject=Email%20Delivery:%20Digest
                                              > 12. mailto:rest-discuss-traditional@yahoogroups.com?subject=Change%20Delivery%20Format:%20Traditional
                                              > 13. http://groups.yahoo.com/group/rest-discuss;_ylc=X3oDMTJkODIwcW9sBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjEzMjE3NDUx
                                              > 14. http://docs.yahoo.com/info/terms/
                                              > 15. mailto:rest-discuss-unsubscribe@yahoogroups.com?subject=
                                              > 16. http://groups.yahoo.com/group/rest-discuss/members;_ylc=X3oDMTJmMGdlcGk1BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzEyMTMyMTc0NTE-
                                              > 17. http://groups.yahoo.com/group/rest-discuss;_ylc=X3oDMTJlaHVrc3JtBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTIxMzIxNzQ1MQ--
                                              > 18. http://us.ard.yahoo.com/SIG=13o761p5q/M=493064.12016257.12445664.8674578/D=groups/S=1705701014:NC/Y=YAHOO/EXP=1213224651/L=/B=GUhoBELaX9E-/J=1213217451885490/A=4507179/R=0/SIG=12de4rskk/*http://us.rd.yahoo.com/evt=50284/*http://finance.yahoo.com/personal-finance
                                              > 19. http://us.ard.yahoo.com/SIG=13of8gpst/M=493064.12016306.12445698.8674578/D=groups/S=1705701014:NC/Y=YAHOO/EXP=1213224651/L=/B=GkhoBELaX9E-/J=1213217451885490/A=4763762/R=0/SIG=11ou7otip/*http://advision.webevents.yahoo.com/bestofyahoogroups/
                                              > 20. http://us.ard.yahoo.com/SIG=13o47de48/M=493064.12662708.12980600.8674578/D=groups/S=1705701014:NC/Y=YAHOO/EXP=1213224651/L=/B=G0hoBELaX9E-/J=1213217451885490/A=5349272/R=0/SIG=11nhsqmjq/*http://advision.webevents.yahoo.com/EverydayWellness/
                                            • Michael Schuerig
                                              ... I don t know, that s why I asked. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/
                                              Message 22 of 28 , Jun 11, 2008
                                              • 0 Attachment
                                                On Wednesday 11 June 2008, Aristotle Pagaltzis wrote:
                                                > * Michael Schuerig <michael@...> [2008-06-11 09:40]:
                                                > > I don't want to use a cookie, that's more or less the whole
                                                > > point of my original message. I know how to get what I want
                                                > > with a cookie, my question is, whether I can get the same
                                                > > result without a cookie.
                                                >
                                                > Ah, I sort of missed that part. How could you possibly do that?

                                                I don't know, that's why I asked.

                                                Michael

                                                --
                                                Michael Schuerig
                                                mailto:michael@...
                                                http://www.schuerig.de/michael/
                                              Your message has been successfully submitted and would be delivered to recipients shortly.