4 ms·

Since a number of people have mentioned point #6 (Sessions are irrelevant), I have a question: Can anyone point to a concrete, more detailed discussion of how t

Since a number of people have mentioned point #6 (Sessions are irrelevant), I have a question: Can anyone point to a concrete, more detailed discussion of how to do authentication and authorization in a RESTful manner? I may be missing something very obvious, but I just don't see how this should/can/might look. (Just to be explicit, I'm not trolling. I'm confused.)

derefr 17y ago
Basically, http://en.wikipedia.org/wiki/Digest_access_authentication#Example_with_explanation http://en.wikipedia.org/wiki/Digest_access_authentication#Ex... but with anything you like in place of the GET.
- kmt 17y ago
  Is the well known and used cookie based authentication in conflict with REST? In my mind it's not, it's orthogonal to it. If not logged in, redirect to a login page (resource) which upon success redirects back, e.g. GET login?next=desired_resource. If logged in but not authorized to perform the action on the resource return 401. That's it basically, isn't it? Also not trolling, challenge me if I'm missing something please.
  - daredevildave 17y ago
    Cookie-based authentication is generally only applicable to the browser interface. From my point of view where REST really shines is at the API level. HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) is good at the API level where you send your credentials with each request.
    - kmt 17y ago
      What if you have to serve both interactive users and automatic clients? Would you use the url structure for both or would you have a separate api structure?
    - derefr 17y ago
      > HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) You know, with all the little browser-chrome experiments that have been going on lately, I'm really surprised that no one has tried to make HTTP-authentication-based login/logout/account management as painless as HTML-served variants. I'd imagine that it would couple with the little "lock" icon in the URL/status bar, making it have four states instead of two: "insecure, secure, insecurely logged in, and securely logged in" where clicking on it brings up a menu to both view credentials and change your password/edit profile/log out/close account/sign up/anything else browser makers want to implement. (They could be distinct, of course, but I like the idea of making "insecure" look scary so that users would be deterred from sending credentials through it.
steveklabnik 17y ago
If you know Ruby, you could check out AuthLogic.
carpo 17y ago
One way to do this is to have the clients pass the authentication information in the headers with every request.
gthank 17y ago
The HTTP spec includes the Basic and Digest methods of auth.

derefr 17y ago

Basically, http://en.wikipedia.org/wiki/Digest_access_authentication#Example_with_explanation http://en.wikipedia.org/wiki/Digest_access_authentication#Ex... but with anything you like in place of the GET.

kmt 17y ago
Is the well known and used cookie based authentication in conflict with REST? In my mind it's not, it's orthogonal to it. If not logged in, redirect to a login page (resource) which upon success redirects back, e.g. GET login?next=desired_resource. If logged in but not authorized to perform the action on the resource return 401. That's it basically, isn't it? Also not trolling, challenge me if I'm missing something please.
- daredevildave 17y ago
  Cookie-based authentication is generally only applicable to the browser interface. From my point of view where REST really shines is at the API level. HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) is good at the API level where you send your credentials with each request.
  - kmt 17y ago
    What if you have to serve both interactive users and automatic clients? Would you use the url structure for both or would you have a separate api structure?
  - derefr 17y ago
    > HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) You know, with all the little browser-chrome experiments that have been going on lately, I'm really surprised that no one has tried to make HTTP-authentication-based login/logout/account management as painless as HTML-served variants. I'd imagine that it would couple with the little "lock" icon in the URL/status bar, making it have four states instead of two: "insecure, secure, insecurely logged in, and securely logged in" where clicking on it brings up a menu to both view credentials and change your password/edit profile/log out/close account/sign up/anything else browser makers want to implement. (They could be distinct, of course, but I like the idea of making "insecure" look scary so that users would be deterred from sending credentials through it.

steveklabnik 17y ago

If you know Ruby, you could check out AuthLogic.

carpo 17y ago

One way to do this is to have the clients pass the authentication information in the headers with every request.

gthank 17y ago

The HTTP spec includes the Basic and Digest methods of auth.