fixed in trunk.
On Dec 27, 11:43 am, alexandremasbr <[email protected]> wrote: > 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 > >
