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

REST authentication representation query

Expand Messages
  • rest_ilyas
    Hello This is my first post which is going to be first of many. The company I work for have started to create RESTful services with most of the development
    Message 1 of 6 , Jul 13, 2011
    View Source
    • 0 Attachment
      Hello

      This is my first post which is going to be first of many. The company I work for have started to create RESTful services with most of the development being outsourced.

      Our first service is for user authentication. When a user enters an incorrect username and password the browser receives a status code of 200 and the response body representation is:

      {
      "state": "FAILED",
      "responseCode": 400,
      "timestamp": 1310378271300,
      "anies": [
      {
      "errorCode": "-6600",
      "errorType": "MSG_ERR_EMPTY_ACCOUNT_API_KEY",
      "translation": {
      "lang": "en",
      "value": "Provided login is empty"
      },
      "property":"apiKey"
      },
      {
      "errorCode": "-6601",
      "errorType": "MSG_ERR_EMPTY_ACCOUNT_API_PASSWORD",
      "translation": {
      "lang":"en",
      "value":"Provided password is empty"
      },
      "property": "apiPassword"
      }
      ]
      }

      The browser interacts with a controller which in turn calls a web service. We will have clients interacting with the services directly.

      The representation above contains the state of failure (400), an internal error code so a client of the service can look up what the error is in a particular language and a translation of the error which the browser will use to display on screen. The "property" attribute is the form element/ parameter the error corresponds to. 

      This feels incorrect to me. 
      1. Should the browser receive a status code of 400 and then look at the representation why it failed? 
      2. Should there be a attribute for translated text or would it make sense to have the text already translated if the accept header is en, fr, etc?

      Thank you









    • Ruben Verborgh
      Hi, ... A 200 status code indicate success, and this is not the case. Currently, your example is not RESTful, e.g., you re not using HTTP as intended, but
      Message 2 of 6 , Jul 13, 2011
      View Source
      • 0 Attachment
        Hi,

        > • Should the browser receive a status code of 400 and then look at the representation why it failed?

        A "200" status code indicate success, and this is not the case.
        Currently, your example is not RESTful, e.g., you're not using HTTP as intended, but rather as a tunnel protocol.

        But you shouldn't return 400, which would mean that the request has a bad syntax. Rather, return 401Unauthorized, which can be used for both "no credentials" and "wrong credentials".

        > • Should there be a attribute for translated text or would it make sense to have the text already translated if the accept header is en, fr, etc?

        You should indeed use the Accept-Language header and try to match the preferences of the user.
        If no language is specified, use a default.

        Cheers,

        Ruben
      • Ruben Verborgh
        ... I disagree here. The request for the resource was NOT successful. Yes, the client was able to reach the server and the server was able to return a
        Message 3 of 6 , Jul 13, 2011
        View Source
        • 0 Attachment
          > The confusion arising here is because the web browser is talking to a controller which in turn talks to the web services, the web service will return 400/401 to the server-side controller but because the request was still successful the web browser receives a 200 OK.

          I disagree here. The request for the resource was NOT successful.
          Yes, the client was able to reach the server and the server was able to return a response, so the HTTP communication was successful. But the request was not. If it was, the client would have bypassed authentication.

          It does not really matter how it works behind the scenes. If you're doing REST, getting a resource without proper authentication should return 401.

          > JavaScript is then used to validate the JSON to see if it was successful. I would like to just confirm with you as it is difficult finding any material on a web browser using a controller. All the examples and books I have read are clients/browser talking directly to the web services.

          That doesn't make any difference, as I argued before.

          > If a client is talking to the web services directly then we will return 401 with a message of validation failed.

          Why would you want to act differently?
          Well, you can… but then it's not REST.

          Can you clarify the function of the controller? Why is it in between, and is this necessary at all?

          Cheers,

          Ruben
        • Eric J. Bowman
          ... Your responses are mostly spot-on; however, there s nothing inherently wrong with a 200 response for unauthorized users. An authentication challenge is
          Message 4 of 6 , Jul 13, 2011
          View Source
          • 0 Attachment
            Ruben Verborgh wrote:
            >
            > It does not really matter how it works behind the scenes. If you're
            > doing REST, getting a resource without proper authentication should
            > return 401.
            >

            Your responses are mostly spot-on; however, there's nothing inherently
            wrong with a 200 response for unauthorized users. An authentication
            challenge is not a requirement of REST or HTTP. Another option is 403.

            But you're right in this case -- the OP is breaking the layered-system
            constraint by returning the actual error in the payload instead of as a
            status code, based on an implementation detail which (in REST) is
            opaque behind the uniform interface. What happens when one back-end
            process talks to another over HTTP (or any other protocol) is none of
            the requesting clients' business; the request it made failed, whether
            or not some back-end HTTP request succeeded.

            -Eric
          • Eric J. Bowman
            ... The REST architectural style doesn t use request brokers. This may well be how your system works in practice, but conceptually it s at odds with the REST
            Message 5 of 6 , Jul 13, 2011
            View Source
            • 0 Attachment
              "rest_ilyas" wrote:
              >
              > The browser interacts with a controller which in turn calls a web
              > service.
              >

              The REST architectural style doesn't use request brokers. This may
              well be how your system works in practice, but conceptually it's at
              odds with the REST method of user-agents interacting directly with
              object interfaces. Design your controller as a web service, instead,
              which encapsulates the other web service (?) while abstracting away any
              need for user-agents to understand the other service.

              -Eric
            • Ruben Verborgh
              ... I agree that it is not a requirement of REST or HTTP, but it is a requirement for this particular application (as far as I understood from the question).
              Message 6 of 6 , Jul 13, 2011
              View Source
              • 0 Attachment
                > there's nothing inherently
                > wrong with a 200 response for unauthorized users. An authentication
                > challenge is not a requirement of REST or HTTP. Another option is 403.


                I agree that it is not a requirement of REST or HTTP, but it is a requirement for this particular application (as far as I understood from the question). Here, an unauthorized user cannot access the resource, so it seems appropriate to return an error code. Otherwise, the payload should be parsed to understand that authentication is required, which is probably not what we want.

                Cheers,

                Ruben
              Your message has been successfully submitted and would be delivered to recipients shortly.