Massimo,
I find the answer, but there is a bug, anyway.
The id have to be send by POST, but generates a error caused by a typo
in tools.py
if requested_id == DEFAULT and not rquest.post_vars:
NameError: global name 'rquest' is not defined
Please correct it.
Alexandre
On 27 dez, 15:26, alexandremasbr <[email protected]> wrote:
> Massimo,
>
> I used impersonation in a app, and update to 1.91.4, and it don't work
> anymore, using the described in the book.
>
> How it works now?
>
> Alexandre
>
> On 8 dez, 05:16, mdipierro <[email protected]> wrote:
>
>
>
> > I will add logging.
>
> > Mind that it has pointed out that impersonate/0 presents a mild
> > security risk. We have already changed the impersonate action in trunk
> > and not you have to submit the user_id via POST to impersonate.
>
> > I am still not 100% happy with this but since it is a security issue
> > we are breaking backward compatibility for this action. The change for
> > you will be minimal.
>
> > Massimo
>
> > On Dec 8, 1:12 am, Markus Schmitz <[email protected]> wrote:
>
> > > Hi everybody,
>
> > > I am working on a new site, where we also plan to use the
> > > impersonation feature for support purposes, which is very helpful.
> > > The impersonation works perfectly, but it looks like there is no log
> > > in the auth_event table of this happening.
>
> > > Is this intended or did I look at the wrong place?
>
> > > Also as I can go back to the original user with impersonate/0, where
> > > does web2py store the original user? We could use this to store on
> > > each update and create not only the current user, but also the actual
> > > user (similar to the effective and actual user id in unix systems).
>
> > > Regards
>
> > > Markus
