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

Re: [rest-discuss] URIs are RESTful

Expand Messages
  • Alex Jacobson
    --On Thursday, July 03, 2003 2:42 AM -0400 Tyler Close ... Preempting Paul.... There are occasions when you want to restrict or control
    Message 1 of 55 , Jul 3, 2003
    • 0 Attachment
      --On Thursday, July 03, 2003 2:42 AM -0400 Tyler Close <tyler@...>
      wrote:
      > I would like to see your demonstration that HTTP Auth is necessary
      > to the REST model.

      Preempting Paul....

      There are occasions when you want to restrict or control who has access to
      a resource.
      How would you provide the services of RestAuthenticateBank or AuthorizeBank
      without HTTP-auth or an equivalent mechanism?

      Note: You could be right that use of these mechanisms is un-RESTful, but
      that would make REST pretty useless.

      -Alex-

      ___________________________________________________________________
      S. Alexander Jacobson i2x Media
      1-212-787-1914 voice 1-603-288-1280 fax
    • Alex Jacobson
      The only thing that a proxy decides based on the content of the auth headers is caching and if you do cookie-auth you just do more explicit cache-control. And
      Message 55 of 55 , Jul 25, 2003
      • 0 Attachment
        The only thing that a proxy decides based on the content of the auth
        headers is caching and if you do cookie-auth you just do more explicit
        cache-control. And if you are doing auth-related stuff, you should be
        doing more explicit cache control anyway so I don't see the value that
        special purpose auth headers provide.

        -Alex-


        ___________________________________________________________________
        S. Alexander Jacobson i2x Media
        1-212-787-1914 voice 1-603-288-1280 fax

        --On Thursday, July 24, 2003 11:17 PM -0400 Chuck Hinson
        <cmhinson@...> wrote:

        >
        >
        > S. Alexander Jacobson wrote:
        >
        >> cookie-based and HTTP auth are identical when the
        >> client is software. The only difference is the
        >> name of the HTTP header in which the
        >> authentication token is passed. But really the
        >> whole premise of HTTP auth is unreasonable for
        >> automated clients. Clients just send a secret
        >> token. They don't need a mnemonic separating
        >> usernames from passwords.
        >>
        >> For human users, the login form that comes in the
        >> 401 response is as visible as you want. In
        >> practice Mozilla appears to auto-fill most login
        >> forms I reach correctly and without issue which
        >> makes me think that visibility is a non-issue.
        >>
        >> -Alex-
        >>
        >>
        >>
        > Hmmm. I thought visibility was about the ability of
        > components/intermediaries to understand the meaning of the message.
        > I.e., a proxy can't tell whether or not a cookie contains auth info
        > since it doesnt know the syntax of what's been packed in the cookie.
        > However, it does know what the HTTP auth header means, and thus knows
        > what it can or cant do with the message (and its response). (This all
        > may be moot as far as auth headers and cookies go since I think many
        > proxies wont cache things with cookies in them).
        >
        > --Chuck
        >
        >> On Thu, 24 Jul 2003, Chuck Hinson wrote:
        >>
        >>
        >>
        >>> Alex Jacobson wrote:
        >>>
        >>>
        >>>
        >>>> --On Wednesday, July 23, 2003 2:53 PM -0700 "Roy T. Fielding"
        >>>> <fielding@...> wrote:
        >>>>
        >>>>
        >>>>
        >>>>
        >>>>> You should note that there is no design reason why Authorization
        >>>>> and WWW-Authenticate are limited to Basic and Digest. That is why
        >>>>> those fields are extensible. Why would you want to duplicate that
        >>>>> functionality in another field?
        >>>>>
        >>>>>
        >>>>>
        >>>>>
        >>>> With all due respect, given that HTTP authentication is fundamentally
        >>>> broken*, that cookies are a defacto standard, and that HTTP-auth is
        >>>> poorly supported by actual UAs. The bigger question is why duplicate
        >>>> cookie functionality with auth-specific headers?
        >>>>
        >>>>
        >>>>
        >>>>
        >>> I would think that while cookies may be a defacto standard, cookie-based
        >>> authentication is not (i.e., there is no standard implementation of
        >>> authentication using cookies). Thus, it would seem to me that
        >>> visibility still suffers.
        >>>
        >>> --Chuck
        >>>
        >>>
        >>>
        >>>
        >>
        >>
        >>
        >>
        >
        >
        >
        > 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/
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.