-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Just one more comment: I wrote hash(SALT+request.url+'#'+user_id) but
meant hash(SUPER_SECRET_GLOBAL_PASSWORD+request.url+'#'+user_id)
El 01/07/15 a las 00:06, Pablo Angulo escribió:
>
> 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 :-) !
>
> --
> 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 a topic in the
Google Groups "web2py-users" group.
> To unsubscribe from this topic, visit
https://groups.google.com/d/topic/web2py/QtP9re5WqqE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
web2py+unsubscr...@googlegroups.com
<mailto:web2py+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
--
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.
