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

Re: Pretty URLs, sessions, and no cookies

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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.