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

Re: [rest-discuss] Can ReST replace cookies?

Expand Messages
  • Elliotte Harold
    ... Cool! I ll have to remember this. One minor point. You write The HTTP spec doesn t say we re allowed to have URLs with usernames and passwords in them so
    Message 1 of 34 , Jun 1, 2006
    • 0 Attachment
      Seairth Jacobs wrote:

      > Check out
      > http://www.peej.co.uk/articles/http-auth-with-html-forms.html. I can
      > also see some variations on this theme to allow a "logout" sort of
      > function which is also a regular complaint about HTTP authentication.
      >

      Cool! I'll have to remember this.

      One minor point. You write "The HTTP spec doesn't say we're allowed to
      have URLs with usernames and passwords in them so we can't guarentee
      that they work anywhere else either."

      It's not really the HTTP spec that's relevant. It's the URI spec, RFC
      3986. What that says is:

      The userinfo subcomponent may consist of a user name and, optionally,
      scheme-specific information about how to gain authorization to access
      the resource. The user information, if present, is followed by a
      commercial at-sign ("@") that delimits it from the host.

      userinfo = *( unreserved / pct-encoded / sub-delims / ":" )

      Use of the format "user:password" in the userinfo field is
      deprecated. Applications should not render as clear text any data
      after the first colon (":") character found within a userinfo
      subcomponent unless the data after the colon is the empty string
      (indicating no password). Applications may choose to ignore or
      reject such data when it is received as part of a reference and
      should reject the storage of such data in unencrypted form. The
      passing of authentication information in clear text has proven to be
      a security risk in almost every case where it has been used.


      --
      ´╗┐Elliotte Rusty Harold elharo@...
      Java I/O 2nd Edition Just Published!
      http://www.cafeaulait.org/books/javaio2/
      http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
    • Jon Hanna
      ... Actually it *is* the HTTP spec that is important here - in how it uses the URI spec in defining HTTP URIs (not all items that can be parts of a valid URI
      Message 34 of 34 , Jun 1, 2006
      • 0 Attachment
        Elliotte Harold wrote:
        > One minor point. You write "The HTTP spec doesn't say we're allowed to
        > have URLs with usernames and passwords in them so we can't guarentee
        > that they work anywhere else either."
        >
        > It's not really the HTTP spec that's relevant. It's the URI spec, RFC
        > 3986. What that says is:
        >
        > The userinfo subcomponent may consist of a user name and, optionally,
        > scheme-specific information about how to gain authorization to access
        > the resource. The user information, if present, is followed by a
        > commercial at-sign ("@") that delimits it from the host.
        >
        > userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
        >
        > Use of the format "user:password" in the userinfo field is
        > deprecated.

        Actually it *is* the HTTP spec that is important here - in how it uses
        the URI spec in defining HTTP URIs (not all items that can be parts of a
        valid URI can be used with all URI schemes).

        The HTTP URI scheme is defined by RFC2616 as:

        "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

        So not only does the HTTP spec not say you allowed to have usernames and
        passwords in URIs, but actively prohibits it - such URIs do not match
        the sheme-specific syntax.

        Supporting such URIs as an extension has become less popular since they
        were used in many spoofing attacks (IE stopping it entirely, Firefox
        allowing it, but prompting you first).
      Your message has been successfully submitted and would be delivered to recipients shortly.