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

Re: [rest-discuss] uFormats applied to the URI

Expand Messages
  • Jan Algermissen
    Jonathan, ... I think it greatly clarifies the essentials of REST if you think in terms of changes to be made to clients when the resource implementations
    Message 1 of 89 , Mar 17, 2006
    • 0 Attachment
      Jonathan,

      > On 3/16/06, Jonathan Arkell <yahoo@...> wrote:
      >> Apparently I have more homework to do...

      I think it greatly clarifies the essentials of REST if you think in
      terms of changes to be made to clients when the resource
      implementations change. Especially consider clients that you do not
      control, e.g. because they are managed by some other IT department
      (quite common in enterprise IT nowadays that the "1 enterprise - 1
      administrator" assumtion does not hold anymore :o)

      I found myself in a situation a while ago where the upgrade cost of
      clients was unexpectedly high and at that point I suddenly realized
      what benefits REST brings in in terms of decoupling.

      HTH,

      Jan
      ________________________________________________________________________
      _______________
      Jan Algermissen, Consultant & Programmer
      http://jalgermissen.com
      Tugboat Consulting, 'Applying Web technology to enterprise IT'
      http://www.tugboat.de
    • Bill Venners
      Hi Jonathan, ... In my scheme the only state stored on the server, and replicated among all the servers, is a pair of passwords used to encrypt the cookies.
      Message 89 of 89 , Mar 28, 2006
      • 0 Attachment
        Hi Jonathan,

        > Really, I wonder if you can meet your needs with REST at all. See,
        > the
        > clincher for me is the timing out of user logins, because you need to
        > store the state of the user somewhere on the server to know when to
        > time
        > them out. Perhaps my method (storing the session as a resource) is
        > RESTfully not REST :P ? At least this way the client has some kind of
        > control over the session, and the session isn't interfering with the
        > cachability.
        >
        In my scheme the only state stored on the server, and replicated
        among all the servers, is a pair of passwords used to encrypt the
        cookies. These passwords expire every 30 minutes, and I keep two
        around (so I replicate a new one every 15 minutes). I'm planning on
        keeping a cache of roles and permissions for users once they log in,
        which can be accessed by the session id. I'll use sticky sessions so
        requests to that site always go back to the server where the cache
        is. It is just a cache, though. It will go into the cache with a
        timeout, and can be evicted early if memory gets full. If that
        happens, or a server crashes, or someone clicks over to a URL at a
        different site in the network served up by a different server, and a
        request comes in with a session ID that doesn't reference anything in
        the roles/permissions cache, I just use the password to decrypt the
        session ID and reauthenticate the user.

        I don't think there's really any "state of the user somewhere on the
        server," at least nothing that can't be uniquely referenced with a
        URI. (All theory. I haven't implemented it yet.)

        > Why avoid iframes? Avoiding Javascript seems cut and dried, what are
        > the issues with Iframes?
        >
        No good reason, actually, just fear of the unknown. I'll look into it.

        By the way, I think I came up with another way to log people off of
        an HTTP auth session if JavaScript is enabled on the client. You need
        some kind of password that no one can have. For example, if you
        require that passwords are at least six chars long, then no one can
        have the password "abc". When you want to log someone out (because
        they've pressed the "Log Out" button for example), some JavaScript on
        the client can run and do an HTTP authentication for the realm you
        want to log the user out of at a special URI with the user's username
        and the password "abc". This authentication will succeed at that
        special URI, which now means that the next time someone goes to any
        other URI in that realm at that site from that client, it will
        attempt to authenticate with the wrong password. You have effectively
        logged the user out of his or her auth session for that realm.

        Bill



        > Bill Venners wrote:
        >
        >> I had to think about this idea for a bit, and am still not quite
        >> sure I
        >> understand it fully. One problem I believe I see is that it doesn't
        >> provide the server with a sure-fire way to recognize the client,
        >> so it
        >> won't always know for which realm to prompt authentication. I.e.,
        >> if you
        >> use a different realm string for each session, then the server
        >> needs to
        >> know what realm string to prompt for in its 401 response on a
        >> request.
        >> Once authenticated, the client may preemptively send the
        >> Authorization
        >> header, but the realm is buried inside the digest-response, and
        >> anyway
        >> the client may not send it until getting a 401. But before the server
        >> sends the 401, it needs to know the realm. So really I think the
        >> realm
        >> needs to something the server can determine from the request URI.
        >>
        >> The other concern is that a URL like this:
        >>
        >> http://yoursite/sessions/SessionID
        >>
        >> seems to indicate I've created state on the server for the auth
        >> session,
        >> which is something I'd rather avoid. I would prefer the auth state
        >> to be
        >> on the client, so when a user creates an auth session, that state
        >> is on
        >> the client for the duration of the session, after which it gets
        >> cleared.
        >> On each request during the auth session, the auth state goes from
        >> client
        >> to the server. This my current best understanding of what REST says
        >> about authentication. (Even though you've taken the innovative
        >> step of
        >> giving the session a URI on the server, it still feels to me like
        >> it's
        >> in the wrong place there on the server.)
        >>
        >> My understanding of why REST suggests we avoid session state (almost
        >> every web framework makes using session state easy), is that extra-
        >> URI
        >> state breaks caching and hinders scalability. There are good
        >> answers to
        >> scalability with session state too, such as cache coherence tools and
        >> several other techniques, but I really don't think it would be
        >> harder to
        >> build a RESTful HTTP app then a stateful one if you just keep REST in
        >> mind as you go.
        >>
        >> I know Roy complained about the use of cookies for session IDs in his
        >> dissertation. My guess is that his main concern was that in practice
        >> session cookies are used not just for auth, usually, but to point to
        >> session state on the server. The cookies I've been considering
        >> using in
        >> our new architecture are really auth tokens. They will essentially
        >> contain the username and password hash encrypted with a password that
        >> all the servers will share for a half hour, after which they'll all
        >> forget it. So if you bring a server up cold, and it gets one of these
        >> cookies within the half-hour timeout, it can figure out who you
        >> are and
        >> authenticate you (with the caveat that the session cookie can be
        >> easily
        >> hijacked). In this approach once the server sends back this
        >> cookie, it
        >> really represents the authentication state sitting there in the
        >> client,
        >> and it gets sent up to the server with each request. The server can
        >> forget all about the authentication, so long as it remembers the
        >> half-hour passwords used to encrypt the cookies.
        >>
        >>
        >>> As for sending out personalized content... what about an iframe?
        >>> Enclose all personalizable content inside of an iframe, and make a
        >>> secondary request for that personalized content. This helps to
        >>> avoid
        >>> the Javascript issue (while opening up another can of iframe
        >>> worms mind
        >>> you).
        >>>
        >>>
        >> I don't think I want to go there. I don't want to go to JavaScript
        >> either, to assemble the personalized representation on the client.
        >> I see
        >> how that would reduce server load and bandwidth, but in exchange for
        >> that cost savings, I'd have the expense of testing a lot more
        >> JavaScript
        >> in a lot more places. I expect I'll just send out personalized
        >> representations of resources, each with their own ETag.
        >>
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.