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

Varying content by user or role

Expand Messages
  • mgvelvet
    I have a business requirement to secure certain data within a resource. For example, in a personnel record, I must not return the salary amount unless the user
    Message 1 of 19 , Mar 24, 2004
    • 0 Attachment
      I have a business requirement to secure certain data within a
      resource. For example, in a personnel record, I must not return the
      salary amount unless the user is in an accounting or HR role.
      Another example: any collection of customers must return only the
      subset the user is authorized to see.

      I can vary the content based on who has authenticated, but I have an
      uneasy feeling that isn't RESTful. On the other hand, different URIs
      for each user seems to fragment the information space.

      Has anyone addressed a similar requirement? What are your thoughts?

      --m
    • Paul Jimenez
      currentuser=foo in the querystring sounds RESTful.. it s just an unusual kind of query, no? and maybe it s the default query so it doesn t have to actually
      Message 2 of 19 , Mar 24, 2004
      • 0 Attachment
        currentuser=foo in the querystring sounds RESTful.. it's just
        an unusual kind of query, no? and maybe it's the 'default'
        query so it doesn't have to actually be there to be in effect.
        And maybe trying to specify currentuser=bar if you're logged
        in as foo results in an 'unauthorized' result. My question is:
        what's your RESTful login resource look like?

        --pj

        On Wednesday, Mar 24, 2004, "mgvelvet" writes:
        >I have a business requirement to secure certain data within a
        >resource. For example, in a personnel record, I must not return the
        >salary amount unless the user is in an accounting or HR role.
        >Another example: any collection of customers must return only the
        >subset the user is authorized to see.
        >
        >I can vary the content based on who has authenticated, but I have an
        >uneasy feeling that isn't RESTful. On the other hand, different URIs
        >for each user seems to fragment the information space.
        >
        >Has anyone addressed a similar requirement? What are your thoughts?
        >
        > --m
        >
        >
        >
        >
        >Yahoo! Groups Links
        >
        >
        >
        >
        >
      • Jon Hanna
        ... There are three approaches I ve used with similar problems in the past: 1. Vary content according to user: Pro: a. Relatively simple URI space. Con: b.
        Message 3 of 19 , Mar 25, 2004
        • 0 Attachment
          Quoting mgvelvet <mgarland@...>:

          > I have a business requirement to secure certain data within a
          > resource. For example, in a personnel record, I must not return the
          > salary amount unless the user is in an accounting or HR role.
          > Another example: any collection of customers must return only the
          > subset the user is authorized to see.
          >
          > I can vary the content based on who has authenticated, but I have an
          > uneasy feeling that isn't RESTful. On the other hand, different URIs
          > for each user seems to fragment the information space.
          >
          > Has anyone addressed a similar requirement? What are your thoughts?

          There are three approaches I've used with similar problems in the past:

          1. Vary content according to user:
          Pro:
          a. Relatively simple URI space.
          Con:
          b. Caching is effectively killed, or at most reduced to end-point private
          caching (but caching sensitive data brings on it's own headaches).

          2. Vary content according to user - have a userID in the URI.
          Pro:
          a. Beats me, but this approach finds its way into specs quite a bit.
          Con:
          b. Caching "works" but because the URI is per-user it's little different than
          end-point private caching. Indeed it's worst because it brings the possibility
          of security issues or difficulties caused by buggy caches but without the
          advantages of intermeditary caching.
          b. Duplicates the authentication procedure, since we can't trust the userID to
          be correct, we must still check the user's credentials and act appropriately.
          c. Reduces the ease with which URIs can be shared (although we can redirect to
          an appropriate URI with the appropriate userID).

          3. Split the content, in this case having say /personnel/employee3 and
          /personnel/employee3/salary. The representation of the former would link to the
          latter (whether a client could also just append /salary depends on your
          position on opacity). The credentials needed to access /personnel/employee3
          would differ from those needed to access /personnel/employee3/salary.
          Pro:
          a. Caching works correctly. It may be necessary to prevent the caching of
          /personnel/employee3/salary through caching directives and/or an encrypted
          connection, but whatever decision is taken here doesn't hurt the caching of
          /personnel/employee3.
          b. There is now a clearer mapping between "resources" and "permissions". It's
          easier for both the programmer of the client and the user to understand why
          they cannot see something. Security errors ("You do not have permission...")
          can be more easily detected and triggered.
          Con:
          a. Requires more client-server interactions (although the connection can be
          kept
          open, much as the case of a webpage with images with HTTP1.1).
          b. Complicates the URI space, although since this complication reflects
          something inherent to the system modelled that could be considered a Pro as
          much as it's considered a Con.

          In all I prefer the last.

          Another thing I've thought about, but haven't done is:
          4. Return a resource which includes encrypted information about salary as well
          as unencrypted information about those details accessible by all.
          Pro:
          a. Okay to be honest I thought about this because I want an excuse to play with
          XML Encryption, but that's still a "pro".
          b. Caching works - the response can be cached for as long as both the
          information and the key used for encryption are both valid.
          c. Caching is secure as even if someone gets unauthorised access to cached
          representations the sensitive data within that representation is encrypted.
          Con:
          a. The overhead of building and using the appropriate cryptographic
          infastructure.
          b. The fact that non-specialists tend to get encryption wrong. It's definitely
          something to thread lightly with.
          c. A change to the key must be considered a modification to the representation
          of the resource. It may not be easy to reflect this in Last-Modified and E-Tag
          headers.

          Some of the above are more easily used with a "Full View With Errors" pattern
          and some with a "Limited View" pattern. However it's possible to present either
          view to the user with any of the above approaches, so which of those patterns
          to use is still very much a seperate design decision.

          --
          Jon Hanna
          <http://www.hackcraft.net/>
          "…it has been truly said that hackers have even more words for
          equipment failures than Yiddish has for obnoxious people." - jargon.txt
        • John Belmonte
          ... Regarding con 4c, it s even worse than that, as message encryption may incorporate a timestamp or some random value (at least I know it s true for
          Message 4 of 19 , Mar 25, 2004
          • 0 Attachment
            Jon Hanna wrote:
            > 3. Split the content, in this case having say /personnel/employee3 and
            ...
            > Another thing I've thought about, but haven't done is:
            > 4. Return a resource which includes encrypted information about salary as well
            > as unencrypted information about those details accessible by all.
            > Pro:
            > a. Okay to be honest I thought about this because I want an excuse to play with
            > XML Encryption, but that's still a "pro".
            > b. Caching works - the response can be cached for as long as both the
            > information and the key used for encryption are both valid.
            > c. Caching is secure as even if someone gets unauthorised access to cached
            > representations the sensitive data within that representation is encrypted.
            > Con:
            > a. The overhead of building and using the appropriate cryptographic
            > infastructure.
            > b. The fact that non-specialists tend to get encryption wrong. It's definitely
            > something to thread lightly with.
            > c. A change to the key must be considered a modification to the representation
            > of the resource. It may not be easy to reflect this in Last-Modified and E-Tag
            > headers.

            Regarding con 4c, it's even worse than that, as message encryption may
            incorporate a timestamp or some random value (at least I know it's true
            for OpenPGP). So every time the server encrypts a given message, the
            HTTP response entity will be different. Anyway, you can still get by
            with weak entity tags.

            I use a combination of your methods 3 and 4, which may seem odd. It's a
            long story, but my app requires message-unit authentication (that is,
            the client must be able to prove that the server produced a message even
            after the HTTP session has ended). Since I'm already signing each
            message, it's not much of a leap to encrypt per-message also, and so I
            don't use session-unit authentication or encryption at all (that is, no
            SSL), which works out nice for caching. I have a public and private
            tree, both accessible without authentication, and producing entities
            signed by the server. In the private tree, the entities are also
            encrypted to the owner.

            -John


            --
            http:// if ile.org/
          • neil_j_k
            ... (I replied to the author directly, by mistake; here s a follow-up that s more complete). I m not a REST expert, but I don t think one needs to resort to
            Message 5 of 19 , Mar 30, 2004
            • 0 Attachment
              --- In rest-discuss@yahoogroups.com, "mgvelvet" <mgarland@f...> wrote:

              > On the other hand, different URIs
              > for each user seems to fragment the information space.

              (I replied to the author directly, by mistake; here's a follow-up
              that's more complete).

              I'm not a REST expert, but I don't think one needs to resort to query
              params or sliced-up URI namespaces. We have standards for
              authentication in HTTP and my gut reaction was that they count.

              1. Userinfo can be be part of a URI and thus it is by definition part
              of REST. See RFC 2396, look for userinfo.

              A URI could look like http://username@host/some/resource and then
              provoke a 401 Unauthorized response, which would explain how the
              useragent should authenticate itself.


              2. But more generally, you're allowed to take other non-URI
              information into account when designing a REST service.

              For example, content-negotiation headers can request a representation
              of the resource in the client's preferred format. So it seems the URI
              identifies the resource, but not necessarily the representation.
              That's right in the REST paper.


              3. Authentication is usually achieved in HTTP/1.1 using headers and is
              thus superficially similar to the content-negotiation case. So you
              could filter content based on user and still claim RESTfulness.

              There are some more subtle issues regarding authentication that Roy
              discusses in the REST paper but this answer still looks correct to me.
            • Jon Hanna
              ... That is not a valid http URI (and those clients and servers which allow them have practical issues as well). ... I wouldn t say it s incorrect (apart from
              Message 6 of 19 , Mar 30, 2004
              • 0 Attachment
                > A URI could look like http://username@host/some/resource and then
                > provoke a 401 Unauthorized response, which would explain how the
                > useragent should authenticate itself.

                That is not a valid http URI (and those clients and servers which allow them
                have practical issues as well).

                > 3. Authentication is usually achieved in HTTP/1.1 using headers and is
                > thus superficially similar to the content-negotiation case. So you
                > could filter content based on user and still claim RESTfulness.
                >
                > There are some more subtle issues regarding authentication that Roy
                > discusses in the REST paper but this answer still looks correct to me.

                I wouldn't say it's incorrect (apart from the username@ in the URI), but there
                are advantages to some of the other approaches. I focused a lot on caching in
                my answer to this thread (which included the above approach and some others and
                tried to weigh them up) because caching is a bit of a hobbyhorse for me and a
                big part of why I personally like REST as a practical solution. My answer was
                hardly comprehensive and I'm sure that more advantages and disadvantages for
                each of the approaches, and indeed other viable approaches, can be found.

                --
                Jon Hanna
                <http://www.hackcraft.net/>
                "…it has been truly said that hackers have even more words for
                equipment failures than Yiddish has for obnoxious people." - jargon.txt
              • neil_j_k
                ... RFC 2396 section 3.2.2 appears to allow this.
                Message 7 of 19 , Mar 30, 2004
                • 0 Attachment
                  --- In rest-discuss@yahoogroups.com, Jon Hanna <jon@h...> wrote:

                  > > A URI could look like http://username@host/some/resource

                  > That is not a valid http URI (and those clients and servers
                  > which allow them have practical issues as well).

                  RFC 2396 section 3.2.2 appears to allow this.
                • Mark Baker
                  ... It s section 3.2.2 in 2616 that you should be looking at. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                  Message 8 of 19 , Mar 30, 2004
                  • 0 Attachment
                    On Wed, Mar 31, 2004 at 01:35:49AM -0000, neil_j_k wrote:
                    > --- In rest-discuss@yahoogroups.com, Jon Hanna <jon@h...> wrote:
                    >
                    > > > A URI could look like http://username@host/some/resource
                    >
                    > > That is not a valid http URI (and those clients and servers
                    > > which allow them have practical issues as well).
                    >
                    > RFC 2396 section 3.2.2 appears to allow this.

                    It's section 3.2.2 in 2616 that you should be looking at.

                    Mark.
                    --
                    Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                  • Neil Kandalgaonkar
                    ... You guys are right and I was wrong. HTTP s scheme-specific syntax overrides the generic URI syntax. Also, this feature was removed with recent a Internet
                    Message 9 of 19 , Mar 30, 2004
                    • 0 Attachment
                      --- In rest-discuss@yahoogroups.com, Mark Baker <distobj@a...> wrote:

                      > It's section 3.2.2 in 2616 that you should be looking at.

                      You guys are right and I was wrong. HTTP's scheme-specific syntax
                      overrides the generic URI syntax.

                      Also, this feature was removed with recent a Internet Explorer patch
                      (MS04-004) so for many practical purposes the whole thing is moot.

                      Sorry for the tangent.

                      I hope the general point, that authentication and REST can co-exist,
                      was on the money.

                      --
                      Neil Kandalgaonkar <neil_j_k@...>
                    • Michael Smith
                      Does anyone have experience with how real-world proxies handle caching of http-authenicated representations (as in 1. Vary content according to user ) ? I m
                      Message 10 of 19 , Mar 31, 2004
                      • 0 Attachment
                        Does anyone have experience with how real-world proxies
                        handle caching of http-authenicated representations (as in
                        "1. Vary content according to user") ?

                        I'm considering using this tactic for personalising certain
                        pages, while keeping the URI the same for everyone. But I'm
                        a little worried that some proxy and UA implementations
                        might not handle this correctly/consistently/as-I-expect.

                        I've used "2. ... have a userID in the URI." approach before
                        and it does feel the safer option (ie.
                        "http://example.org/recent-changes/mike", not
                        "http://mike@...").

                        Also, in 14.8 - 1 & 2 in rfc2616, when it says;

                        "If the response includes the 'must-revalidate'
                        cache-control directive, the cache MAY use that response in
                        replying to a subsequent request."

                        Does it mean that it MAY use that cached response in
                        replying to a subsequent request CONTAINING THE SAME
                        AUTHORIZATION HEADERS (user&password) ? Or, does it mean it
                        may use the cached response in reply to any request FOR THAT
                        URI ?

                        --
                        Michael Smith
                        Strategic Management Systems Ltd
                        michaelsmith@...
                        http://www.smslimited.com/
                      • Jon Hanna
                        The more I think about this the more I m unhappy with the idea of varying content per user. If two pieces of information have different permissions relating to
                        Message 11 of 19 , Apr 2, 2004
                        • 0 Attachment
                          The more I think about this the more I'm unhappy with the idea of varying
                          content per user. If two pieces of information have different permissions
                          relating to them then it should be because they are representations of two
                          different (if related) resources that in turn should have two different URIs.

                          I don't think the inclusion or exclusion of sensitive data is comparable to the
                          other reasons for content negotiation (content type, content language etc.).

                          The main reason for taking the approach of varying content per user in
                          traditional web applications is to offer a limited-view rendering rather than a
                          full-view-with-errors rendering. In the case of an application which is giving
                          a human user (or another process) a view onto information obtained from a web
                          service then it can do the necessary attempts to download restricted data and
                          hence the limited-view pattern is possible by using several URIs.

                          Even in the case of a browser-based web app using XSLT this would be possible if
                          it were possible to trap errors with document() calls. Alas whether the errors
                          are signalled or not is implementation-defined.

                          --
                          Jon Hanna
                          <http://www.hackcraft.net/>
                          "…it has been truly said that hackers have even more words for
                          equipment failures than Yiddish has for obnoxious people." - jargon.txt
                        • Paul Jimenez
                          ... Consider a /MyHome resource that is, admittedly, just a shortcut to /Home/me , but is still useful, just like ~/ is useful in shells. ... What about
                          Message 12 of 19 , Apr 2, 2004
                          • 0 Attachment
                            On Friday, Apr 2, 2004, Jon Hanna writes:
                            >The more I think about this the more I'm unhappy with the idea of
                            >varying content per user. If two pieces of information have different
                            >permissions relating to them then it should be because they are
                            >representations of two different (if related) resources that in turn
                            >should have two different URIs.

                            Consider a '/MyHome' resource that is, admittedly, just a shortcut to
                            '/Home/me', but is still useful, just like ~/ is useful in shells.

                            >I don't think the inclusion or exclusion of sensitive data is
                            >comparable to the other reasons for content negotiation (content type,
                            >content language etc.).

                            What about niceties like not exposing knobs to the user that the user
                            can't twiddle? For instance, an admin-level user will have options
                            to modify a resource that a normal user won't have available... or
                            what about something like user-definable formatting prefs? I like my
                            /datetime resource formatted differently than you do, so my display of
                            this data is different than yours, based on us having different logins.

                            >The main reason for taking the approach of varying content per user
                            >in traditional web applications is to offer a limited-view rendering
                            >rather than a full-view-with-errors rendering. In the case of an
                            >application which is giving a human user (or another process) a
                            >view onto information obtained from a web service then it can do
                            >the necessary attempts to download restricted data and hence the
                            >limited-view pattern is possible by using several URIs.
                            >
                            >Even in the case of a browser-based web app using XSLT this would be
                            >possible if it were possible to trap errors with document() calls. Alas
                            >whether the errors are signalled or not is implementation-defined.

                            Well, I see the issue as basically resource-specific gradations between
                            'full access' and '401 Unauthorized'. The extremes are clearly allowed;
                            why not the middle?

                            --pj
                          • John Coe
                            ... From: Paul Jimenez [mailto: pj@place.org]To: rest-discuss@yahoogroups.comDate: Fri, 02 Apr 2004 11:13:36 -0600Subject: Re: [rest-discuss] Varying content
                            Message 13 of 19 , Apr 2, 2004
                            • 0 Attachment






                              --- On Fri 04/02, Paul Jimenez < pj@... > wrote:

                              From: Paul Jimenez [mailto: pj@...]
                              To: rest-discuss@yahoogroups.com
                              Date: Fri, 02 Apr 2004 11:13:36 -0600
                              Subject: Re: [rest-discuss] Varying content by user or role

                              On Friday, Apr 2, 2004, Jon Hanna writes:

                              >
                              >Even in the case of a browser-based web app using XSLT this would be
                              >possible if it were possible to trap errors with document() calls. Alas
                              >whether the errors are signalled or not is implementation-defined.

                              Well, I see the issue as basically resource-specific gradations between
                              'full access' and '401 Unauthorized'. The extremes are clearly allowed;
                              why not the middle?

                              --pj

                              If the CGI(or other server orb) gives a XHTML return, that document() can read, the error condition can be handled. I'm accessing a TWiki from a document() call and sometimes get a page missing or locked by other user, In this case a :

                              xsl:template match="xhtml:input/@value='error'"

                              should catch the error.

                              A client XSL document call is a great place to use REST. it may also provide a security layer. if the XSL is on the server with a document(http....) the url is kept away from the user!




                              Join Excite! - http://www.excite.com
                              The most personalized portal on the Web!
                            • Jon Hanna
                              ... This is what I refer to earlier as limited-view . I contrasted this to full-view-with-errors which is where you give all users all the controls and then
                              Message 14 of 19 , Apr 5, 2004
                              • 0 Attachment
                                > What about niceties like not exposing knobs to the user that the user
                                > can't twiddle? For instance, an admin-level user will have options
                                > to modify a resource that a normal user won't have available... or

                                This is what I refer to earlier as "limited-view". I contrasted this to
                                "full-view-with-errors" which is where you give all users all the controls and
                                then shout at them if they press the wrong one. These are the names given to
                                those patterns in
                                <http://www.joeyoder.com/papers/patterns/Security/appsec.pdf>.

                                My point being that it's perfectly possible for a client to use either pattern
                                whether the web service it uses presents all the relevant information in one
                                response or many.

                                > what about something like user-definable formatting prefs? I like my
                                > /datetime resource formatted differently than you do, so my display of
                                > this data is different than yours, based on us having different logins.

                                In a case where it is necessary to deliver a human-readable representation
                                directly from the server (i.e. web sites) then this can be a tricky issue. In
                                the example of dates we have a choice of either customising the representation
                                per user, or of using a format that is unambiguous even when it is less than
                                ideal (e.g. "2004-04-05", "5<sup>th</sup> of April, 2004" and "April 5, 2004"
                                are all unambiguous, 04/05/2004 and 05/04/2004 are useless[1]). There are quite
                                a few issues either way.

                                In the case of a REST service where the server is sending data then one would
                                just send the data in an appropriate format for the machine (in the case of
                                dates we would use one of the profiles of ISO 8601 common on the web) and
                                presenting this to any user can become the client's job (which is in a much
                                better position to reliably determine locale settings than the server).

                                I'm less dogmatic about per-user representations in the case of stylesheets
                                precisely because they deal with such issues although a user-stylesheet
                                mechanism could better deal with this. However I try to put any per-user-agent
                                hacks into the CSS alone when it comes to websites.

                                > Well, I see the issue as basically resource-specific gradations between
                                > 'full access' and '401 Unauthorized'. The extremes are clearly allowed;
                                > why not the middle?

                                Authorised and unauthorised are concepts understood by the system. The rest of
                                the system (caching, firewalls) can understand them. An admin looking at the
                                traffic can understand them. Providing partial access through allowing full or
                                no access to related resources is merely expressing this gradiated security in
                                a way the system understands. It's also similar to how other authorisation for
                                file-based, RDBMS-based and other systems works (either you can read or you
                                can't, either you can write or you can't, etc) and hence concepts of
                                authorisation that developers are used to building and security people are used
                                to auditing.

                                [1] An aside on this issue. I have an article on my site about date formats and
                                the web, focusing mainly on the behind-the-scene formats. Referrer logs
                                indicate that there are a large number of people looking to use mm/dd/yyyy with
                                XML Schemata, and a roughly equal number of people looking to use dd/mm/yyyy.
                                Amusingly the words "normal", "more common" and "natural" appear in the query
                                strings from both groups.

                                --
                                Jon Hanna
                                <http://www.hackcraft.net/>
                                "…it has been truly said that hackers have even more words for
                                equipment failures than Yiddish has for obnoxious people." - jargon.txt
                              • Jon Hanna
                                ... Examining the spec indicates that if a document() gets a 401 it could either lose or return the empty nodeset: If there is an error retrieving the
                                Message 15 of 19 , Apr 5, 2004
                                • 0 Attachment
                                  > If the CGI(or other server orb) gives a XHTML return, that document() can
                                  > read, the error condition can be handled. I'm accessing a TWiki from a
                                  > document() call and sometimes get a page missing or locked by other user, In
                                  > this case a :

                                  Examining the spec indicates that if a document() gets a 401 it could either
                                  lose or return the empty nodeset:

                                  "If there is an error retrieving the resource, then the XSLT processor may
                                  signal an error; if it does not signal an error, it must recover by returning
                                  an empty node-set." <http://www.w3.org/TR/xslt#document>

                                  It would seem therefore that either your XSLT engine is non-conformant in not
                                  exhibiting one of the two behaviours allowed above, or that the TWiki is
                                  sending 2xx statuses with error pages.

                                  That said, I like your approach and wanted to do exactly the same thing
                                  recently. It would be nice if there was a lower-level document() function that
                                  gave us the status and access to the document returned even if it was an error
                                  page. That wouldn't be protocol-agnostic, but maybe something along those lines
                                  could be fitted into XSLT (say giving us a protocol-defined status, a boolean
                                  indicating whether this was an error or not, and the nodeset).

                                  > xsl:template match="xhtml:input/@value='error'"

                                  > should catch the error.

                                  > A client XSL document call is a great place to use REST.

                                  Agreed.

                                  it may also provide
                                  > a security layer. if the XSL is on the server with a document(http....) the
                                  > url is kept away from the user!

                                  Keeping URIs away from users is more æsthetics than security.

                                  --
                                  Jon Hanna
                                  <http://www.hackcraft.net/>
                                  "…it has been truly said that hackers have even more words for
                                  equipment failures than Yiddish has for obnoxious people." - jargon.txt
                                • John Coe
                                  Jon:The xsl:fallback should be able to catch the 401 errors. If the CGI produces a XHTML error form then it can be used by both users and processes. Here is a
                                  Message 16 of 19 , Apr 5, 2004
                                  • 0 Attachment
                                    Jon:
                                    The xsl:fallback should be able to catch the 401 errors. If the CGI produces a XHTML error form then it can be used by both users and processes.

                                    Here is a link to some notes on using XSL with a wiki to produce a REST interface. It uses Google search as one of it's service.
                                    http://twiki.org/cgi-bin/view/Codev/XslWiki
                                    There are working samples in linked pages, but they are still primitive and under construction.

                                    The URL hiding is a security advantage especially when the querystring parameters are hidden. If the XSL is attached to the server in a way that the end user can't access it, the details of the web service are kept from the user, even when the XSL is executing on the client.

                                    John


                                    --- On Mon 04/05, Jon Hanna < jon@... > wrote:

                                    From: Jon Hanna [mailto: jon@...]
                                    To: rest-discuss@yahoogroups.com
                                    Date: Mon, 5 Apr 2004 12:06:00 +0100
                                    Subject: Re: [rest-discuss] Varying content by user or role

                                    > If the CGI(or other server orb) gives a XHTML return, that document() can
                                    > read, the error condition can be handled. I'm accessing a TWiki from a
                                    > document() call and sometimes get a page missing or locked by other user, In
                                    > this case a :

                                    Examining the spec indicates that if a document() gets a 401 it could either
                                    lose or return the empty nodeset:

                                    "If there is an error retrieving the resource, then the XSLT processor may
                                    signal an error; if it does not signal an error, it must recover by returning
                                    an empty node-set." <http://www.w3.org/TR/xslt#document>

                                    It would seem therefore that either your XSLT engine is non-conformant in not
                                    exhibiting one of the two behaviours allowed above, or that the TWiki is
                                    sending 2xx statuses with error pages.

                                    That said, I like your approach and wanted to do exactly the same thing
                                    recently. It would be nice if there was a lower-level document() function that
                                    gave us the status and access to the document returned even if it was an error
                                    page. That wouldn't be protocol-agnostic, but maybe something along those lines
                                    could be fitted into XSLT (say giving us a protocol-defined status, a boolean
                                    indicating whether this was an error or not, and the nodeset).

                                    > xsl:template match="xhtml:input/@value='error'"

                                    > should catch the error.

                                    > A client XSL document call is a great place to use REST.

                                    Agreed.

                                    it may also provide
                                    > a security layer. if the XSL is on the server with a document(http....) the
                                    > url is kept away from the user!

                                    Keeping URIs away from users is more �sthetics than security.

                                    --
                                    Jon Hanna
                                    <http://www.hackcraft.net/>
                                    "�it has been truly said that hackers have even more words for
                                    equipment failures than Yiddish has for obnoxious people." - jargon.txt



                                    Join Excite! - http://www.excite.com
                                    The most personalized portal on the Web!
                                  • Paul Jimenez
                                    ... Right, and this is my point: varying content by user/role is, I think, a valid thing to do. In fact, arguably putting the userid in the querystring is a
                                    Message 17 of 19 , Apr 5, 2004
                                    • 0 Attachment
                                      On Monday, Apr 5, 2004, Jon Hanna writes:
                                      >> what about something like user-definable formatting prefs? I like my
                                      >> /datetime resource formatted differently than you do, so my display of
                                      >> this data is different than yours, based on us having different logins.
                                      >
                                      >In a case where it is necessary to deliver a human-readable representation
                                      >directly from the server (i.e. web sites) then this can be a tricky issue. In
                                      >the example of dates we have a choice of either customising the representation
                                      >per user, or of using a format that is unambiguous even when it is less than
                                      >ideal (e.g. "2004-04-05", "5<sup>th</sup> of April, 2004" and "April 5, 2004"
                                      >are all unambiguous, 04/05/2004 and 05/04/2004 are useless[1]). There are quite
                                      >a few issues either way.

                                      Right, and this is my point: varying content by user/role is, I think, a valid
                                      thing to do. In fact, arguably putting the userid in the querystring is a valid
                                      thing to do since it is, in essence, a parameter to the 'view' of a resource:
                                      'This resource as viewed by userid X'.

                                      >In the case of a REST service where the server is sending data then one would
                                      >just send the data in an appropriate format for the machine (in the case of
                                      >dates we would use one of the profiles of ISO 8601 common on the web) and
                                      >presenting this to any user can become the client's job (which is in a much
                                      >better position to reliably determine locale settings than the server).

                                      Sure; offloading the problem to the client is a fine thing, when you've got
                                      one :)

                                      >> Well, I see the issue as basically resource-specific gradations between
                                      >> 'full access' and '401 Unauthorized'. The extremes are clearly allowed;
                                      >> why not the middle?
                                      >
                                      >Authorised and unauthorised are concepts understood by the system. The rest of
                                      >the system (caching, firewalls) can understand them. An admin looking at the
                                      >traffic can understand them. Providing partial access through allowing full or
                                      >no access to related resources is merely expressing this gradiated security in
                                      >a way the system understands. It's also similar to how other authorisation for
                                      >file-based, RDBMS-based and other systems works (either you can read or you
                                      >can't, either you can write or you can't, etc) and hence concepts of
                                      >authorisation that developers are used to building and security people are used
                                      >to auditing.

                                      Binary auth/unauth acces is fine for individual resources, but fails for aggregate
                                      resources where low-clearance people need partial access to the same resource that
                                      high-clearance people get full access to. I guess the question boils down to:
                                      does/should security policy impact resource definition?


                                      --pj
                                    • Jon Hanna
                                      ... That s what I thought when I started down the same route recently. When it failed to work I re-read the spec and it appears tht xsl:fallback only catches
                                      Message 18 of 19 , Apr 5, 2004
                                      • 0 Attachment
                                        Quoting John Coe <jcoe18@...>:

                                        > Jon:The xsl:fallback should be able to catch the 401 errors.

                                        That's what I thought when I started down the same route recently. When it
                                        failed to work I re-read the spec and it appears tht xsl:fallback only catches
                                        errors resulting from unknown elements or functions used in forwards-compatible
                                        mode, not as a general error handling mechanism.

                                        That's the theory part. In practice at least one commonly used XSLT engine goes
                                        b0rk.

                                        http://twiki.org/cgi-bin/view/Codev/XslWikiThere are working samples
                                        > in linked pages, but they are still primitive and under construction.

                                        I'm getting "This Wiki topic does not exist yet ", misspelled URI?

                                        --
                                        Jon Hanna
                                        <http://www.hackcraft.net/>
                                        "…it has been truly said that hackers have even more words for
                                        equipment failures than Yiddish has for obnoxious people." - jargon.txt
                                      • johncoe42
                                        Jon: Sorry I posted an unusable link, here is the link to some notes on using the document function of XSL for REST.
                                        Message 19 of 19 , Apr 6, 2004
                                        • 0 Attachment
                                          Jon:
                                          Sorry I posted an unusable link, here is the link to some notes on
                                          using the document function of XSL for REST.

                                          http://twiki.org/cgi-bin/view/Codev/XslWiki

                                          When you attempt to access
                                          http://twiki.org/cgi-bin/view/Codev/ThisPageDoesNotExist , you get
                                          the "This Wiki topic does not exist yet ". if xsl document function
                                          attempted get the non-existing page from the CGI, a CGI could detect
                                          content unique to the recovery page (like the This Wiki topic does
                                          not exist yet screen) that it can process in most cases The TWiki
                                          CGI can catch the error.

                                          A CGI can catching the 401 error, and provide a page that can be
                                          processed. This was my real point.

                                          At least in the MSIE xsl client case, when you do get an 401 error,
                                          it produces a XHTML compatable error that can be processed also.
                                          John.
                                          --- In rest-discuss@yahoogroups.com, Jon Hanna <jon@h...> wrote:
                                          > Quoting John Coe <jcoe18@E...>:
                                          >
                                          > > Jon:The xsl:fallback should be able to catch the 401 errors.
                                          >
                                          > That's what I thought when I started down the same route recently.
                                          When it
                                          > failed to work I re-read the spec and it appears tht xsl:fallback
                                          only catches
                                          > errors resulting from unknown elements or functions used in
                                          forwards-compatible
                                          > mode, not as a general error handling mechanism.
                                          >
                                          > That's the theory part. In practice at least one commonly used
                                          XSLT engine goes
                                          > b0rk.
                                          >
                                          > http://twiki.org/cgi-bin/view/Codev/XslWikiThere are working
                                          samples
                                          > > in linked pages, but they are still primitive and under
                                          construction.
                                          >
                                          > I'm getting "This Wiki topic does not exist yet ", misspelled URI?
                                          >
                                          > --
                                          > Jon Hanna
                                          > <http://www.hackcraft.net/>
                                          > "…it has been truly said that hackers have even more words for
                                          > equipment failures than Yiddish has for obnoxious people." -
                                          jargon.txt
                                        Your message has been successfully submitted and would be delivered to recipients shortly.