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

Re: [rest-discuss] Authorization and Statelessness

Expand Messages
  • mike amundsen
    Shea: Why doesn t authorization violate the statelessness constraint of REST? It seems to reduce visibility (monitoring systems need to know both the
    Message 1 of 4 , Dec 10, 2012
    • 0 Attachment
      Shea:

      <snip>
      Why doesn't authorization violate the statelessness constraint of REST?
      It seems to reduce visibility (monitoring systems need to know both the
      request datum AND the user's access rights to understand a request) 
      </snip>
      you can use the Authorization header to make the auth info visible

      server's don't need to "understand" access rights, just apply them. think about cases where the authentication is done by party A (oAuth), the authorization list is handled by party B (UMA), and the source material to access is handled by party C.

      <snip>
      and scalability (server needs to store access-control metadata across
      requests). 
      </snip>
      there is no requirement that servers MUST store AC data across requests. in fact, i don't to this in my work. maybe an auth proxy does it, however.

      </snip>
      What makes this different from, say, personalizing a response
      based on the client's username?
      </snip>





      On Mon, Dec 10, 2012 at 3:32 PM, Shea Levy <shea@...> wrote:
      Hi all,

      Why doesn't authorization violate the statelessness constraint of REST?
      It seems to reduce visibility (monitoring systems need to know both the
      request datum AND the user's access rights to understand a request) and
      scalability (server needs to store access-control metadata across
      requests). What makes this different from, say, personalizing a response
      based on the client's username?

      Cheers,
      Shea Levy


      ------------------------------------

      Yahoo! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/rest-discuss/

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          http://groups.yahoo.com/group/rest-discuss/join
          (Yahoo! ID required)

      <*> To change settings via email:
          rest-discuss-digest@yahoogroups.com
          rest-discuss-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
          rest-discuss-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/


    • Eric J. Bowman
      ... There s nothing inherently unRESTful about personalization. Basing it on digest auth gives us caching advantages over both cookies, and tying it to
      Message 2 of 4 , Dec 10, 2012
      • 0 Attachment
        Shea Levy wrote:
        >
        > What makes this different from, say, personalizing a response based
        > on the client's username?
        >

        There's nothing inherently unRESTful about personalization. Basing it
        on digest auth gives us caching advantages over both cookies, and tying
        it to /{username}/ URI allocation schemes. What we're after in REST is
        optimizing the hell out of GET, remember...

        Say I have a resource called "newsletter" I want all guests to be able
        to read, personalized for registered members using client-side XSLT to
        handle the mail-merge. The HTML representation of the newsletter must
        be the same for all users so we can set cache-control: public. It
        contains code which calls an XSLT transformation residing in an
        external .xsl file, whose URL must not vary for the sake of caching.

        But, that .xsl resource doesn't need to return the same representation
        for all users. The personal.xsl resource sets Vary: Authorization and
        has no 401 or 403 response. It has a 200 OK response which sets cache-
        control: public for unauthorized users, personalizing the newsletter for
        "Guest" (as opposed to, say, "Dave") which functions as a login link;
        whereas Dave would be linked to his control-panel UI. For example.

        Authenticated users GET a 303 redirection to the personal.xsl file in
        their user directory, which has cache-control: private set. Note that
        the personal.xsl files in this example apply to all newsletters, so
        it's useful to cache them. Note also that this is all invisible to the
        user, dereferencing the newsletter resource results in a personalized
        newsletter application steady-state -- which is a representation of the
        newsletter resource the user dereferenced.

        Actually, the HTML representation should be personalized for Guest by
        default, with the guest personal.xsl file containing an identity
        transform (does nothing). Also, the 303 redirects are cache-control:
        private.

        We can expand the example to only work this way for user-agents which
        Accept: application/xhtml+xml (which all do client-side XSLT 1 nowadays)
        while performing the XSLT transformation server-side and sending the
        personalized 200 OK response as text/html with cache-control: private
        for other user-agents (public, if not logged in). What this does is
        expand the set of representations such that each user now has two
        possible 200 OK responses, HTML and XHTML. Don't forget Vary: Accept.

        This isn't "the" RESTful way to do personalization, merely my attempt
        at a very simple example of basic mail-merge functionality in the REST
        idiom, to help answer your questions...

        >
        > Why doesn't authorization violate the statelessness constraint of
        > REST?
        >

        I'm going to turn that around on you, and ask what is it about my
        example you find stateful, specifically?

        >
        > It seems to reduce visibility (monitoring systems need to know
        > both the request datum AND the user's access rights to understand a
        > request)
        >

        Not really; intermediaries just need to know a user *has* access rights.
        As to visibility, if my example didn't have that property, it wouldn't
        have graceful degradation from highly-cacheable client-side merging
        down to cache-miss server-side merging.

        >
        > and scalability (server needs to store access-control metadata across
        > requests).
        >

        Sorry, not seeing it. The access-control metadata is part of the
        request, which leads to scalability. That a cookie is being used as
        access-control metadata is not apparent from such a request. It seems
        to me that the worst-case scenarios in my example, in terms of
        scalability vis-a-vis cache-hit ratio, are the best-case scenarios of
        non-RESTful approaches to personalization.

        IOW, that most requests cause processing on the server is what's
        expected with cookies, while REST gives me the means to avoid even
        contacting the server in many if not most cases, for the given example.
        The more millions of users, the greater the likelihood the newsletter's
        already cached closer to the user than the origin server, meaning
        server resource utilization per-user decreases as users increase, which
        is the real payoff to REST.

        -Eric
      • Mike Kelly
        Eric, Please could you start adding a tl;dr summary to the top of your posts Cheers, M ... -- Mike http://twitter.com/mikekelly85 http://github.com/mikekelly
        Message 3 of 4 , Dec 11, 2012
        • 0 Attachment
          Eric,

          Please could you start adding a tl;dr summary to the top of your posts

          Cheers,
          M


          On Tue, Dec 11, 2012 at 7:24 AM, Eric J. Bowman <eric@...> wrote:
           

          Shea Levy wrote:
          >
          > What makes this different from, say, personalizing a response based
          > on the client's username?
          >

          There's nothing inherently unRESTful about personalization. Basing it
          on digest auth gives us caching advantages over both cookies, and tying
          it to /{username}/ URI allocation schemes. What we're after in REST is
          optimizing the hell out of GET, remember...

          Say I have a resource called "newsletter" I want all guests to be able
          to read, personalized for registered members using client-side XSLT to
          handle the mail-merge. The HTML representation of the newsletter must
          be the same for all users so we can set cache-control: public. It
          contains code which calls an XSLT transformation residing in an
          external .xsl file, whose URL must not vary for the sake of caching.

          But, that .xsl resource doesn't need to return the same representation
          for all users. The personal.xsl resource sets Vary: Authorization and
          has no 401 or 403 response. It has a 200 OK response which sets cache-
          control: public for unauthorized users, personalizing the newsletter for
          "Guest" (as opposed to, say, "Dave") which functions as a login link;
          whereas Dave would be linked to his control-panel UI. For example.

          Authenticated users GET a 303 redirection to the personal.xsl file in
          their user directory, which has cache-control: private set. Note that
          the personal.xsl files in this example apply to all newsletters, so
          it's useful to cache them. Note also that this is all invisible to the
          user, dereferencing the newsletter resource results in a personalized
          newsletter application steady-state -- which is a representation of the
          newsletter resource the user dereferenced.

          Actually, the HTML representation should be personalized for Guest by
          default, with the guest personal.xsl file containing an identity
          transform (does nothing). Also, the 303 redirects are cache-control:
          private.

          We can expand the example to only work this way for user-agents which
          Accept: application/xhtml+xml (which all do client-side XSLT 1 nowadays)
          while performing the XSLT transformation server-side and sending the
          personalized 200 OK response as text/html with cache-control: private
          for other user-agents (public, if not logged in). What this does is
          expand the set of representations such that each user now has two
          possible 200 OK responses, HTML and XHTML. Don't forget Vary: Accept.

          This isn't "the" RESTful way to do personalization, merely my attempt
          at a very simple example of basic mail-merge functionality in the REST
          idiom, to help answer your questions...


          >
          > Why doesn't authorization violate the statelessness constraint of
          > REST?
          >

          I'm going to turn that around on you, and ask what is it about my
          example you find stateful, specifically?


          >
          > It seems to reduce visibility (monitoring systems need to know
          > both the request datum AND the user's access rights to understand a
          > request)
          >

          Not really; intermediaries just need to know a user *has* access rights.
          As to visibility, if my example didn't have that property, it wouldn't
          have graceful degradation from highly-cacheable client-side merging
          down to cache-miss server-side merging.


          >
          > and scalability (server needs to store access-control metadata across
          > requests).
          >

          Sorry, not seeing it. The access-control metadata is part of the
          request, which leads to scalability. That a cookie is being used as
          access-control metadata is not apparent from such a request. It seems
          to me that the worst-case scenarios in my example, in terms of
          scalability vis-a-vis cache-hit ratio, are the best-case scenarios of
          non-RESTful approaches to personalization.

          IOW, that most requests cause processing on the server is what's
          expected with cookies, while REST gives me the means to avoid even
          contacting the server in many if not most cases, for the given example.
          The more millions of users, the greater the likelihood the newsletter's
          already cached closer to the user than the origin server, meaning
          server resource utilization per-user decreases as users increase, which
          is the real payoff to REST.

          -Eric




          --
          Mike

          http://twitter.com/mikekelly85
          http://github.com/mikekelly
          http://linkedin.com/in/mikekelly123
        Your message has been successfully submitted and would be delivered to recipients shortly.