Ok, read it carefully....All of that IMHO isn't really what users wants to implement a token-based auth on top of an API. Apart from the fact that if the scheme of the tokens table gets corrected (a FK to the user_id and token unique) the first two queries are collapsible into one, calling login_user() triggers update_groups() (not sure if an API needs it for every call), plus it renews the session (that in an API isn't there for sure), and creates a new Session (and again, the cookie-based Session isn't something an API uses or requires)
The way I see it, a token-based authentication is good for a kind of cached/speedy authentication. You expect zillion calls to an API and you don't want username/passwords flying around, so you publish something behind the usual auth that generates a code what identifies you. Or you have a zillions mini-programs that needs to call the api and you don't want to store username-password combo in each and every program, so you request a token. Usually the token is also generated for a "scope", so, e.g., the authenticated user with the token can't invalidate all other tokens...of change the profile email, etc etc. This goes beyond the scope of a simple helper in web2py and goes towards being an oauth provider.... an entire different story. Let's assume though that the token auth gets the same permissions as the usual one... who you are (when you generated the token) is only one piece of the info: the other piece is what you're allowed to do with that token. For all intents and purposes, a "token-based" auth for an API IMHO resembles very closely what in non-API environments is persisted in web2py with the Session (under the hook a cookie with the sesson id). Specifically the session.auth part. non-api: You login, the "heavy auth thingies" take place there and only there (are you a valid user, is your password correct, which groups are you in, did you complete the registration process, and so on), and from there on you are issued a "lightweight" Session that relieves web2py from constantly checking at every request who you are and what you can do (through membership) api: you request a token for your login, the "heavy auth thingies" take place there and only there, and you're issued a "lightweight" token (with an optional expiration) that relieves web2py from costantly checking who you are and what can you do. This naming (api_tokens) collides with the implementation: it's slower than the default (thinking about basic auth) because it requires at least 3 queries for any call (1) is there a token, 2) is there a user with that id (duh?), are there groups for that user). On top of that, it creates a new session for every call. As it is, it'd better implemented as a new login method (and BTW, it surely is just a login method), living in contrib. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
