Doing RESTful APIs is indeed a little bit different than regular web interactions. Instead of doing credentials in a cookies and sessions, people are increasingly doing them as tokens sent in HTTP headers across domain boundaries. I’ll describe that below, JSON Web Tokens (JWT):
https://scotch.io/tutorials/the-anatomy-of-a-json-web-token Here’s how the interactions work: - You send a request to the API with no credentials. It replies back with with an HTTP forbidden. - Your API client gets the forbidden and knows it needs to authenticate. It also knows the URL to authenticate against. - It sends a POST to that URL with the login information. The server gets that information — perhaps a username, password, and your “organization” — and validates it. - If valid, the server returns a response body containing the token, which is a payload wrapped in a secure envelope. - The client gets the token and (here’s the first important difference) stores it. In memory, on disk…somewhere. - The client then issues the first request again, this time sending the token in an HTTP header. - The server gets the token and cryptographically unpacks it, then validates if the token is still valid (age, etc.) Read the article for details on tokens. In Pyramid, you can use the nice pyramid_jwtauth package to handle the JWT part, but it presumes you understand setting up Pyramid authentication. It also doesn’t automate things such as handling expired tokens and re-issue. I did a sample applicatino with a pyramid_jwtauth backend and an Angular frontend: https://github.com/pauleveritt/pyramid_satellizer <https://github.com/pauleveritt/pyramid_satellizer> —Paul > On Jan 3, 2016, at 5:21 AM, Krishnakant <krm...@openmailbox.org> wrote: > > Dear all, > I wish to know what are the best practices in RESTful api when managing user > authentication and other persistent data? > I understand as a newbie that REST = totally stateless = no session > persistance on server. > So how do I do the authentication? > I feel that on first time login the user id must be sent back in the response > and then onb every request the id should be passed. > So before doing any activity related to CRUD, the server must check if a user > with that id exists and if he is an admin or a normal user (as is required in > my case). > Is that Correct? > if so then can I do this with more than one parameter? > I also need the orc code for the given organization, as the service may be > used by many organizations who share a common database. > Happy hacking. > Krishnakant. > > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pylons-discuss+unsubscr...@googlegroups.com > <mailto:pylons-discuss+unsubscr...@googlegroups.com>. > To post to this group, send email to pylons-discuss@googlegroups.com > <mailto:pylons-discuss@googlegroups.com>. > Visit this group at https://groups.google.com/group/pylons-discuss > <https://groups.google.com/group/pylons-discuss>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
