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

Re: [rest-discuss] Stateless services requiring authentication in an AJAX application

Expand Messages
  • Moore, Jonathan (CIM)
    HTTPS + login cookie is perfectly stateless from the server side if implemented correctly (as a digitally signed token). There s no reason an AJAX client can t
    Message 1 of 7 , Feb 8, 2012
    View Source
    • 0 Attachment
      HTTPS + login cookie is perfectly stateless from the server side if implemented correctly (as a digitally signed token). There's no reason an AJAX client can't navigate "login" and "logout" link relations and/or forms, as long as they obey the same origin policy. 

      Jon
      ........
      Jon Moore


      On Feb 8, 2012, at 5:59 PM, "Jason Erickson" <jason@...> wrote:

       

      When letting the browser handle it all, how do you handle the "sign out" use case?


      Also, I disagree that this is not related to REST.  A lot of services that are called RESTful but aren't are there to support AJAX.  One big reason they aren't RESTful tends to be a lack of HATEOS.  But even if you do have HATEOS in your AJAX calls, I don't know of anyone who doesn't have a session on the server to keep track of authentication, which also violates REST.  Now, the fact that I don't know anyone doing it is hardly an exhaustive search.  So the question has to do with REST thus:

      1. Can you use truly RESTful web services that require authentication in an AJAX browser-based application.  The answer to this question, from your answer below, is yes.
      2. Should you make those web services RESTful? If the answer to this is "no" then I see your point that this has nothing to do with REST (except to answer that question).  But I think the answer must be "yes, if it's feasible", so my question is about whether it is feasible/practical to do.  Is there a (good) reason no one seems to be doing it?
        • If you have a requirement to have a nice, pretty, branded login screen are you already stuck at that point? You can, with newer browsers, store the login credentials in a local data store to use on subsequent pages, but is that a good idea?
        • Say you only need to support the newer browsers and you don't have a problem storing the credentials in a local store.  You almost certainly have another requirement to let a user "sign out" so that subsequent requests do not get automatically authenticated by the browser.  Is this possible? If it's possible, how practical is it?
      3. If it is practical, how are people doing it? Are there examples to look at for best practices? You provided three examples but even you don't seem very happy with any of them.  Does anyone else have other suggestions?

      On Feb 8, 2012, at 7:23 AM, mike amundsen wrote:

      Interesting HTTP Q (not related to REST, of course)...

      Here's my list of HTTP auth solutions when working w/ common browsers:

      LET THE BROWSER HANDLE IT ALL
      I usually use HTTPS + Basic Auth for browser apps and I let the
      browser handle this detail for me. IOW, I set up the server to require
      auth for the URIs and let things "flow" from there. No special coding
      on the browser client at all.

      SCRIPTED PRE-AUTH
      Occasionally, I'll set up a scripted "pre-auth" on the browser. In
      this case, I use a small JS lib to handle the base64 encoding and
      prompt the user to provide user/pass locally, encode it and stuff it
      into the headers for ajax calls. I do this on every call, tho and that
      can get tedious.

      BASIC AUTH COOKIE HACK
      Finally, (and I'm not really proud of this one....) I sometimes stuff
      the Base64-encoded Basic Auth value as a cookie (sheesh!) and set up
      the server to peek into the cookie space before throwing a 403 upon
      receiving an un-auth'ed request. The advantage here is the cookie is
      retained across pages.

      That's what I do.

      mca
      http://amundsen.com/blog/
      http://twitter.com@mamund
      http://mamund.com/foaf.rdf#me




      On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason@...> wrote:
      I have a web application that has many web services and an AJAX web client as well as some mobile clients.  I won't call them RESTful web services, but I'm trying to get them closer.

      One problem I have is that I am trying to avoid having any application state on the server.  I have that with the exception of having an authenticated session.  Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.

      But I want to get all the way to having no session, but that means I have to authenticate with every request.  My mobile clients have no trouble doing this.  (In fact, they do it already.)  However, this seems to be rather tricky from a browser.

      If the ENTIRE application was in one web page, then you could just store the credentials in memory.  However, if you have to go from one web page to another, it starts to get hairy.

      Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?



      ------------------------------------

      Yahoo! Groups Links

      <*> To visit your group on the web, go to:
         http://groups.yahoo.com/group/rest-discuss/

      <*> Your email settings:
         Individual Email | Traditional

      <*> To change settings online go to:
         http://groups.yahoo.com/group/rest-discuss/join
         (Yahoo! ID required)

      <*> To change settings via email:
         rest-discuss-digest@yahoogroups.com
         rest-discuss-fullfeatured@yahoogroups.com

      <*> 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/


    • mike amundsen
      Jason: SIGN OUT HTTP Auth does not support sign-out so, by default, i do not expect it when using HTTP Auth. However: - when using browser-based auth, this
      Message 2 of 7 , Feb 8, 2012
      View Source
      • 0 Attachment
        Jason:

        SIGN OUT
        HTTP Auth does not support "sign-out" so, by default, i do not expect
        it when using HTTP Auth. However:
        - when using browser-based auth, this is the browser's problem
        - when using my pre-auth option or cookie-hack, i can use a flag to
        "turn off" sending the auth bits on each call

        IS THIS REST?
        as for the whole "is this REST thing" I'll only point out that the
        arch style in Fielding's dissertation has nothing to say about
        authentication patterns. That is why I made the remark at the top.
        This is not me trying to get in a dig or something, just making an
        observation.

        AJAX
        I don't really follow how using XmlHttpRequest object from a browser
        is primary to asking about using HTTP Auth or deciding if an
        implementation follows Fielding's model. For example, I've written
        quite a few "desktop" apps that don't use common browsers (i.e. all
        complied code making direct HTTP calls and parsing the responses) and
        was able to follow Fielding's model w/o any problem. As for "pretty
        login", I think I covered that in the previous post (the pre-auth).

        SESSION STATE
        I suspect part of your question really has to do w/ state-handling
        (not just auth, but the entire notion of maintaining state in a
        dist-net app). Here, Fielding's model declares "Session state is
        therefore kept entirely on the client"[1] to support the Layered
        Sytsem [2] property in his model. And, as you point out, common Web
        browsers make it tough to pull that off since,until recently, their
        support for allowing servers to send code that "writes" state data to
        the client has been limited to the cookie option. Yes, for "modern"
        browsers, there is the WebStorage API that recently hit recommendation
        status[3]. I've not used this in any production code; perhaps others
        can comment on it's usefulness.

        MY SESSION HACK FOR BROWSERS
        For cases where i need to get around the "session state on the client"
        problem common for browsers (no matter how "old" they are), I usually
        create a server-side resource that holds all the "transient state" for
        that logged in user. This is tied to the auth session and usually
        cached w/ an etag to prevent chatty traffic where possible. again,
        it's a hack, but it isolates the problem and makes it possible to:
        - make this "session state" mobile (not tied to any single server),
        - treat is as orthagonal to the server implementation (servers don't
        _do_ anything with this stuff, it's the client that must ask for and
        apply the state upon requests)
        - implementation agnostic (since it's a separated component, future
        client updates can take advantage of changes in state support w/o
        affecting existing server implementations or "older" clients.

        More than once, I've written server implementations that supported
        both "desktop" and "browser" clients. In those cases, the desktop apps
        kept their own state and the browsers used the server-side session
        resources. The server itself (that handled the business scenario)
        never knew the diff.

        Hopefully this gives you some ideas on how to come up w/ a solution
        that will work for your use cases.

        [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
        [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_6
        [3] http://www.w3.org/TR/webstorage/

        mca
        http://amundsen.com/blog/
        http://twitter.com@mamund
        http://mamund.com/foaf.rdf#me




        On Wed, Feb 8, 2012 at 10:23, mike amundsen <mamund@...> wrote:
        > Interesting HTTP Q (not related to REST, of course)...
        >
        > Here's my list of HTTP auth solutions when working w/ common browsers:
        >
        > LET THE BROWSER HANDLE IT ALL
        > I usually use HTTPS + Basic Auth for browser apps and I let the
        > browser handle this detail for me. IOW, I set up the server to require
        > auth for the URIs and let things "flow" from there. No special coding
        > on the browser client at all.
        >
        > SCRIPTED PRE-AUTH
        > Occasionally, I'll set up a scripted "pre-auth" on the browser. In
        > this case, I use a small JS lib to handle the base64 encoding and
        > prompt the user to provide user/pass locally, encode it and stuff it
        > into the headers for ajax calls. I do this on every call, tho and that
        > can get tedious.
        >
        > BASIC AUTH COOKIE HACK
        > Finally, (and I'm not really proud of this one....) I sometimes stuff
        > the Base64-encoded Basic Auth value as a cookie (sheesh!) and set up
        > the server to peek into the cookie space before throwing a 403 upon
        > receiving an un-auth'ed request. The advantage here is the cookie is
        > retained across pages.
        >
        > That's what I do.
        >
        > mca
        > http://amundsen.com/blog/
        > http://twitter.com@mamund
        > http://mamund.com/foaf.rdf#me
        >
        >
        >
        >
        > On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason@...> wrote:
        >> I have a web application that has many web services and an AJAX web client as well as some mobile clients.  I won't call them RESTful web services, but I'm trying to get them closer.
        >>
        >> One problem I have is that I am trying to avoid having any application state on the server.  I have that with the exception of having an authenticated session.  Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.
        >>
        >> But I want to get all the way to having no session, but that means I have to authenticate with every request.  My mobile clients have no trouble doing this.  (In fact, they do it already.)  However, this seems to be rather tricky from a browser.
        >>
        >> If the ENTIRE application was in one web page, then you could just store the credentials in memory.  However, if you have to go from one web page to another, it starts to get hairy.
        >>
        >> Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?
        >>
        >>
        >>
        >> ------------------------------------
        >>
        >> Yahoo! Groups Links
        >>
        >>
        >>
      Your message has been successfully submitted and would be delivered to recipients shortly.