-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This email was going to be a simple "Great!", but eventually I have many
comments:

El 29/06/15 a las 20:37, Massimo Di Pierro escribió:
> 2. yes that is correct (except it is _token=, not token=). Just mind that the 
> token is as good as a
password and may be unsafe to send it via email. If if you need it, you
can do it.

Is it less safe than sending auth.email_reset_password(), which anyone
can ask? Actually, that's my number 1 use case. I want local admins to
register users in bulk, then send each user an email that would
automatically log her in, and send her right into a custom profile page.
Depending on how unsafe it is, I may use for all the other emails, like
for example: "click *here* to accept the new offer but click *here* to
reject it", with no login.


More comments: If I understand the new code correctly:
1- the token is valid until admin explicitely takes action or it expires
by date, but if I want for example one-use-only tokens, I have to write
a custom "requires_login_or_token"
2- no token is created on user creation, so I have to create the tokens
using for example a hook on db.auth_user._after_insert
3- a user can have many tokens, so I could create a token whenever I
send her an email with auto-login. But is this sensible? What is the use
case for having many tokens per user?


Actually, I've been using something related for some time. In some
functions, say for example:

example.com/c/f?a=1&b=2

it is possible to share a link of the kind:

example.com/c/f?a=1&b=2&auth_code=SJAkKS_random_garbage_QWKSDW

If anyone gets the link with the correct auth_code, she can access the
page. Otherwise, permissions depend on auth_membership:

>     auth.basic()                                                              
>   
>     if
productor.random_string==request.vars.auth_code:                         
>        
pass                                                                    
>     elif not
auth.login():                                                      
>         raise HTTP(403, T('You don't have permission. Please log in.'))
>     elif (auth.has_membership(role='admins_%s'%grupo)
or                            
>          
auth.has_membership(role='webadmins')):                               
>         
pass                                                                   
>    
else:                                                                       

>         session.flash = T('You don't have permission.')
>         redirect(URL(...)) 

I don't know if this pattern deserves its own generic implementation.
Something like:
 auth.allow_login_by_keycode=1
that alters the behaviour of all decorators requires_login,
requires_membership, requires, so that:
 - If request.vars._keycode is exactly hash(SALT+request.url), let them in
 - Otherwise, require login, membarship, etc
The admin would then decide when to share to link with the _keycode, if
at all. There should be a function auth.get_keycode(url)...

Maybe we could use hash(SALT+request.url+'#'+user_id) to achieve both
effects: if request.vars._keycode is exactly
hash(SALT+request.url+'#'+user_id), you may access the url as if you
were user_id. If the url is
example.com/user/login?_next=/controller/function%3Fa%3D1&_keycode=XASXA_correct_keycode_ASKAJ,
this automatically logs the user in, and redirects to
example.com/controller/function?a=1, now logged as user_id. But there
would be no need to use different decorators, and it also allows for
other possibilities that I don't think I can do with
requires_login_or_token.

I hope at least one of these comments make sense to you :-) !
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVkxLiAAoJEATsOw+FDrzIhocP/0GUWq9q2bJXDJABXL3aJL0n
a1vTKnGWH00YiyhvXUyMBaIpkqhIj+kK423QVcJjqqEDQyVn2ctn9UhfnywoRUZ/
J18ECE1qZlW2+q44V7+v14s9RjSSNB47EVFfGz2xUv3xRhGYB25DZ/PdB0U2ZV+O
Q4j2/PqG6035IfHkCAX+jYgZLW0sv/KcFF28S0Dk2Ojd5SAWgVGcrz2ujq0jSoJO
SA7hqW1vYGmocAy0nkIM7pWiIoEPDo9UByUvEH/xsn1ArvEe4mQ8BVMry6w438yF
dnmGcPVWxbH5zriRwZEZJtwTvyVMMGLhVvpqkb4fTwSvKXfuZxxnuLCIJsRoaeb+
6o3sgDnzW7AYeds0haJz3MV0XAL9mtvls+aWrY9eAOxIvosT4Nu8e45FFzGrj0nl
maDTVTQJwMcGPqx+eK3FBIdcy0njYBwRvuWr5HJWx/aJf5DN30rUvWADDhH8jQ3d
GQs+3WlXrWrZWfM+yxLDJ/aUczkabZ73OaOb6aPfmzWGXGCEnY9nuYh1PXQIpuC/
ICW6+MZtQlu6Onl3irqt555hGh6SBSmPproFMp0yUiv0GuSvSY4uYP7KhQ9H96DE
NyKEGaWWm0Hhx0ZO8KntINYPbhpnCHIRBJVUpT2XZss6YgX0iMHEhw/GXRO4BryC
A96YHISuVuyCIVpJyg1h
=WSf2
-----END PGP SIGNATURE-----

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

Reply via email to