[web2py] Re: Design flaw in auth.impersonate ?

2015-04-07 Thread Pbop
Presuming the session is cookie based, why not impersonate in incognito mode or in another browser? -- 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

Re: [web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Anthony
Imagine you have -10 years of computer knowledge, and that you’re on the phone with a customer and have to check data on your platform by impersonating him. Most likely, you’re gonna forget that you have to use a separate session and see an error message when trying to reach your

Re: [web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Anthony
Assuming you don't really need admin permissions and impersonated user permissions in the same request, a better approach might be to build the functionality you need into the application (perhaps via a plugin). Before starting impersonation, set a flag in the admin session (e.g.,

[web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Jim S
I agree that impersonate is just right the way it is. -Jim On Sunday, April 5, 2015 at 6:00:52 PM UTC-5, Limedrop wrote: Well the easy answer is to simply open the impersonated user in a different browser (eg, have Support Team login in chrome and impersonated user login in firefox). For

Re: [web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Louis Amon
Well maybe I’m just biased then. I think of web2py as THE framework for startups, and in that regard an easy-to-use user management system seems to me like a priority. With all due respect to Support Team members across the globe, using two browsers isn’t something you should expect from them.

Re: [web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Anthony
On Monday, April 6, 2015 at 11:16:51 AM UTC-4, Louis Amon wrote: Well maybe I’m just biased then. I think of web2py as THE framework for startups, and in that regard an easy-to-use user management system seems to me like a priority. With all due respect to Support Team members across the

Re: [web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Derek
Chrome allows not just incognito mode, but that little person icon in the upper right by the minimize is 'switch account' and you can use a guest account that's not incognito, which is just perfect for testing out stuff like that. On Monday, April 6, 2015 at 9:02:21 AM UTC-7, Anthony wrote:

[web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Leonel Câmara
With all due respect to Support Team members across the globe, using two browsers isn’t something you should expect from them. How hard is it to open a private browsing window of the same browser (ctrl+shift+n)? Not to mention the problems that keeping the permissions of the original user

Re: [web2py] Re: Design flaw in auth.impersonate ?

2015-04-06 Thread Louis Amon
Usually I would agree with you guys : browsers can manage separate sessions perfectly well… but we are all devs here so we have a bias. Imagine you have -10 years of computer knowledge, and that you’re on the phone with a customer and have to check data on your platform by impersonating him.

[web2py] Re: Design flaw in auth.impersonate ?

2015-04-05 Thread Limedrop
Well the easy answer is to simply open the impersonated user in a different browser (eg, have Support Team login in chrome and impersonated user login in firefox). For us it is important that impersonate is restricted to the user's permissions...we have several classes of user and it is

[web2py] Re: Design flaw in auth.impersonate ?

2015-04-05 Thread Massimo Di Pierro
Now I think 3 should be the solution but it should be an option and not default behavior. Nowhere we say that impersonate should behave has linux sudo permissions. The way it is intended to work is that when you impersonate another user you become that other use and you see what the other user