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

cgi generating HTML, do you have a REST example ?

Expand Messages
  • joujans
    First of all, excuse my english, I am dutch. I joined this group because I am interested in REST, there seem to be several good ideas here. I have a
    Message 1 of 55 , Jun 30, 2003
    • 0 Attachment
      First of all, excuse my english, I am dutch. I joined this group
      because I am interested in REST, there seem to be several good ideas
      here.

      I have a webservice that is something like an online civilization
      game. Users can conquer land, cities, build things there, explore
      maps, etc. How do you design something like that RESTful? Can
      something like that be done? I am using Python for cgi scripts,
      generating HTML with CSS inline (by means of style attributes). The
      main thing I don't understand is how to give a player access to
      his/her cities, and denying other players access to those cities.
      HTTPS could be available. As it is now, the webapplication starts
      with asking a username+password combo, and as I understand it that
      is already against REST principles?
    • 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.