Hacker News Reader

Comment by kmt | Hacker News Reader

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.

View on HN

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.

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?

> 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.

Reply on news.ycombinator.com