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

Re: Pretty URLs, sessions, and no cookies

Expand Messages
  • 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 1 of 28 , Jun 10, 2008
    View Source
    • 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 2 of 28 , Jun 11, 2008
      View Source
      • 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 3 of 28 , Jun 11, 2008
        View Source
        • 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 4 of 28 , Jun 11, 2008
          View Source
          • 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 5 of 28 , Jun 11, 2008
            View Source
            • 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 6 of 28 , Jun 11, 2008
              View Source
              • 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 7 of 28 , Jun 11, 2008
                View Source
                • 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 8 of 28 , Jun 11, 2008
                  View Source
                  • 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 9 of 28 , Jun 11, 2008
                    View Source
                    • 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 10 of 28 , Jun 11, 2008
                      View Source
                      • 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 11 of 28 , Jun 11, 2008
                        View Source
                        • 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 12 of 28 , Jun 11, 2008
                          View Source
                          • 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 13 of 28 , Jun 11, 2008
                            View Source
                            • 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 14 of 28 , Jun 11, 2008
                              View Source
                              • 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 15 of 28 , Jun 11, 2008
                                View Source
                                • 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 16 of 28 , Jun 11, 2008
                                  View Source
                                  • 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.