[web2py] Re: Design flaw in auth.impersonate ?
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 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.
Re: [web2py] Re: Design flaw in auth.impersonate ?
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 back-office. Call me an idiot but I’m pretty sure even I would, if caught in the moment. Can't this be handled with some very simple training? Just show them they should keep two tabs open -- one for admin work, and one for impersonating. The UI could also include some instructions/warnings. Anthony -- 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.
Re: [web2py] Re: Design flaw in auth.impersonate ?
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., session.impersonate_id). Then, whenever a request comes in for the admin part of the app, if auth.is_impersonating() is True, pickle the user's session, call auth.impersonate(0), and store the pickled user session in the admin session. When a non-admin request comes in, check for the session.impersonate_id flag, and if present, call auth.impersonate(session.impersonate_id) and update the session with the previously stored user session. You could add UI elements to indicate when impersonation is happening and allow the admin to turn it off at any time. This approach simply switches back and forth between admin permissions and user permissions automatically depending on the request. Anthony On Monday, April 6, 2015 at 12:43:07 PM UTC-4, Louis Amon wrote: 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. Most likely, you’re gonna forget that you have to use a separate session and see an error message when trying to reach your back-office. Call me an idiot but I’m pretty sure even I would, if caught in the moment. I do understand your concern about backwards compatibility though. Maybe the tool I’m looking for is just a full-fledged CRM tool with a badass API. Le 6 avr. 2015 à 18:34, Leonel Câmara leonelcam...@gmail.com a écrit : 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 can have, there might be bugs that the user sees that the support user impersonating won't. This is a bad idea. -- Resources: - http://web2py.com http://mandrillapp.com/track/click/30579528/web2py.com?p=eyJzIjoiSGpyVDZXSjRFODFheHZ3UDBuNnFnSVBzNkc0IiwidiI6MSwicCI6IntcInVcIjozMDU3OTUyOCxcInZcIjoxLFwidXJsXCI6XCJodHRwOlxcXC9cXFwvd2ViMnB5LmNvbVxcXC9cIixcImlkXCI6XCJmYmU1MzVmMDdhZjM0MDFkOThmOTNkZDE2OTZmZjk0ZlwiLFwidXJsX2lkc1wiOltcImQ4NTZmMWRiNzUyMTgzNmMwNmExODkzYjZiNjAyOTZjODYyM2Y2YTJcIl19In0 - http://web2py.com/book http://mandrillapp.com/track/click/30579528/web2py.com?p=eyJzIjoidG5tRUlCOEhOdkpKdWtJSjlyN2IxNHF3aTVNIiwidiI6MSwicCI6IntcInVcIjozMDU3OTUyOCxcInZcIjoxLFwidXJsXCI6XCJodHRwOlxcXC9cXFwvd2ViMnB5LmNvbVxcXC9ib29rXCIsXCJpZFwiOlwiZmJlNTM1ZjA3YWYzNDAxZDk4ZjkzZGQxNjk2ZmY5NGZcIixcInVybF9pZHNcIjpbXCIzZDY5NjU1NDYyMzRmYTRjNjQ3ODRkN2U4NDU2Y2ViMDc1MmFjYzMzXCJdfSJ9 (Documentation) - http://github.com/web2py/web2py http://mandrillapp.com/track/click/30579528/github.com?p=eyJzIjoiS0lsaG5XQ0FqajIxZGhPYk9hTnI4MVYzdzlVIiwidiI6MSwicCI6IntcInVcIjozMDU3OTUyOCxcInZcIjoxLFwidXJsXCI6XCJodHRwOlxcXC9cXFwvZ2l0aHViLmNvbVxcXC93ZWIycHlcXFwvd2ViMnB5XCIsXCJpZFwiOlwiZmJlNTM1ZjA3YWYzNDAxZDk4ZjkzZGQxNjk2ZmY5NGZcIixcInVybF9pZHNcIjpbXCJiYjkxNmIwNzkyODMwZjgwOWJkZTUzNmI3MDEyYmU1NWZiYzllYmZjXCJdfSJ9 (Source code) - https://code.google.com/p/web2py/issues/list http://mandrillapp.com/track/click/30579528/code.google.com?p=eyJzIjoiVHctR01jVUdacGFsX3lkb1ZJdW9ZRG9qaEQ4IiwidiI6MSwicCI6IntcInVcIjozMDU3OTUyOCxcInZcIjoxLFwidXJsXCI6XCJodHRwczpcXFwvXFxcL2NvZGUuZ29vZ2xlLmNvbVxcXC9wXFxcL3dlYjJweVxcXC9pc3N1ZXNcXFwvbGlzdFwiLFwiaWRcIjpcImZiZTUzNWYwN2FmMzQwMWQ5OGY5M2RkMTY5NmZmOTRmXCIsXCJ1cmxfaWRzXCI6W1wiOWUzNWQ2ZWU3MjczYTgyNzY1NWE1OTcyN2M1YTBlYmNiNTcxNGY4N1wiXX0ifQ (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/POYrBeZwvBk/unsubscribe http://mandrillapp.com/track/click/30579528/groups.google.com?p=eyJzIjoiVFM0eDRCODA2U1RCMHREYlFOTzRHMm02XzhvIiwidiI6MSwicCI6IntcInVcIjozMDU3OTUyOCxcInZcIjoxLFwidXJsXCI6XCJodHRwczpcXFwvXFxcL2dyb3Vwcy5nb29nbGUuY29tXFxcL2RcXFwvdG9waWNcXFwvd2ViMnB5XFxcL1BPWXJCZVp3dkJrXFxcL3Vuc3Vic2NyaWJlXCIsXCJpZFwiOlwiZmJlNTM1ZjA3YWYzNDAxZDk4ZjkzZGQxNjk2ZmY5NGZcIixcInVybF9pZHNcIjpbXCIwZjE1MDY2NDE3NWJmM2I5YTAyZTA5MWY5OGQxYzdmMDVjMTg5YTEzXCJdfSJ9 . To unsubscribe from this group and all its topics, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout
[web2py] Re: Design flaw in auth.impersonate ?
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 us it is important that impersonate is restricted to the user's permissions...we have several classes of user and it is essential to see what the site looks like from their environment. On Monday, 6 April 2015 06:51:53 UTC+12, Louis Amon wrote: When you impersonate a user in web2py, your whole auth session gets replaced with the user's, and that means you lose access to whatever permissions you used to have ( http://web2py.readthedocs.org/en/latest/tools.html#gluon.tools.Auth.impersonate ) Practically : if you're a staff member (Support Team, not geek) and you're using a permission-locked back-office to impersonate a user, that means you won't be able to access the back-office to check for extra data until you impersonate(0) to go back to your own session and permissions. So far I've just asked my team to chew on it and just de-impersonate every time they need to go back to the back-office... but they keep complaining about it and they're quite right. I've been thinking about how to improve this, and so far I've only managed to narrow down a few options : 1. Building a second Session() object to manage both sessions separately 2. Using session.connect(masterapp=...) to use another application's sessions (between main app and back-office app for instance, if those are separate... which is a pain in terms of model management) 3. Messing with the permission system to add up permissions (staff member's permissions + impersonated user's permissions) before permission checks I'm really not sure what strategy I should adopt here and how I should go about implementing this. Pointers would be very welcome :) -- 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.
Re: [web2py] Re: Design flaw in auth.impersonate ?
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. Maybe it’s important to « impersonate » exactly a user, being being able to do it ergonomically is just as -if not more- important. I agree with Massimo’s take on this : there should be an option that allows you to keep groups permissions or not when impersonating. I tried implementing it on my own but no luck so far... Le 6 avr. 2015 à 17:05, Jim S j...@qlf.com a écrit : 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 us it is important that impersonate is restricted to the user's permissions...we have several classes of user and it is essential to see what the site looks like from their environment. On Monday, 6 April 2015 06:51:53 UTC+12, Louis Amon wrote: When you impersonate a user in web2py, your whole auth session gets replaced with the user's, and that means you lose access to whatever permissions you used to have (http://web2py.readthedocs.org/en/latest/tools.html#gluon.tools.Auth.impersonate http://web2py.readthedocs.org/en/latest/tools.html#gluon.tools.Auth.impersonate) Practically : if you're a staff member (Support Team, not geek) and you're using a permission-locked back-office to impersonate a user, that means you won't be able to access the back-office to check for extra data until you impersonate(0) to go back to your own session and permissions. So far I've just asked my team to chew on it and just de-impersonate every time they need to go back to the back-office... but they keep complaining about it and they're quite right. I've been thinking about how to improve this, and so far I've only managed to narrow down a few options : Building a second Session() object to manage both sessions separately Using session.connect(masterapp=...) to use another application's sessions (between main app and back-office app for instance, if those are separate... which is a pain in terms of model management) Messing with the permission system to add up permissions (staff member's permissions + impersonated user's permissions) before permission checks I'm really not sure what strategy I should adopt here and how I should go about implementing this. Pointers would be very welcome :) -- Resources: - http://web2py.com http://web2py.com/ - http://web2py.com/book http://web2py.com/book (Documentation) - http://github.com/web2py/web2py http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list 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/POYrBeZwvBk/unsubscribe https://groups.google.com/d/topic/web2py/POYrBeZwvBk/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 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.
Re: [web2py] Re: Design flaw in auth.impersonate ?
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 globe, using two browsers isn’t something you should expect from them. I would think if someone is qualified to provide support for a product, it's not too much to ask that they be able to handle keeping two browsers open (certainly seems easier that what they are already doing, which is logging in and out of their accounts). Actually, you can make it even easier. There are extensions for Chrome https://chrome.google.com/webstore/detail/multilogin/nccllfnllopfpcbjdgjdlfmomnfgnnbk?hl=en and Firefox https://getmultifox.com/ that allow separate sessions in separate tabs. So now all you need is two separate tabs. This is actually superior to the functionality you seek, as it allows you to impersonate multiple users simultaneously (one in each tab) without sharing their permissions. Chrome and Firefox also allow you to set up separate profiles (which have different sessions), and Internet Explorer has a New Session option that opens a window with a new session. Maybe it’s important to « impersonate » exactly a user, being being able to do it ergonomically is just as -if not more- important. I agree with Massimo’s take on this : there should be an option that allows you to keep groups permissions or not when impersonating. It's not necessarily a problem to add an option, but there are trade-offs when deciding to add new functionality. The code becomes more complex, and then the new functionality must be maintained in perpetuity. When we want to make some other alteration or re-factor, we now have to make sure this new functionality continues to work. If the use case is rare or if there is an easy workaround, it might not be worth the effort and added complexity. Whether it's worth it in this case, I don't know -- I suppose it depends on the complexity of the required code. Anthony -- 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.
Re: [web2py] Re: Design flaw in auth.impersonate ?
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: 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 globe, using two browsers isn’t something you should expect from them. I would think if someone is qualified to provide support for a product, it's not too much to ask that they be able to handle keeping two browsers open (certainly seems easier that what they are already doing, which is logging in and out of their accounts). Actually, you can make it even easier. There are extensions for Chrome https://chrome.google.com/webstore/detail/multilogin/nccllfnllopfpcbjdgjdlfmomnfgnnbk?hl=en and Firefox https://getmultifox.com/ that allow separate sessions in separate tabs. So now all you need is two separate tabs. This is actually superior to the functionality you seek, as it allows you to impersonate multiple users simultaneously (one in each tab) without sharing their permissions. Chrome and Firefox also allow you to set up separate profiles (which have different sessions), and Internet Explorer has a New Session option that opens a window with a new session. Maybe it’s important to « impersonate » exactly a user, being being able to do it ergonomically is just as -if not more- important. I agree with Massimo’s take on this : there should be an option that allows you to keep groups permissions or not when impersonating. It's not necessarily a problem to add an option, but there are trade-offs when deciding to add new functionality. The code becomes more complex, and then the new functionality must be maintained in perpetuity. When we want to make some other alteration or re-factor, we now have to make sure this new functionality continues to work. If the use case is rare or if there is an easy workaround, it might not be worth the effort and added complexity. Whether it's worth it in this case, I don't know -- I suppose it depends on the complexity of the required code. Anthony -- 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.
[web2py] Re: Design flaw in auth.impersonate ?
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 can have, there might be bugs that the user sees that the support user impersonating won't. This is a bad idea. -- 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.
Re: [web2py] Re: Design flaw in auth.impersonate ?
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. Most likely, you’re gonna forget that you have to use a separate session and see an error message when trying to reach your back-office. Call me an idiot but I’m pretty sure even I would, if caught in the moment. I do understand your concern about backwards compatibility though. Maybe the tool I’m looking for is just a full-fledged CRM tool with a badass API. Le 6 avr. 2015 à 18:34, Leonel Câmara leonelcam...@gmail.com a écrit : 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 can have, there might be bugs that the user sees that the support user impersonating won't. This is a bad idea. -- Resources: - http://web2py.com http://web2py.com/ - http://web2py.com/book http://web2py.com/book (Documentation) - http://github.com/web2py/web2py http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list 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/POYrBeZwvBk/unsubscribe https://groups.google.com/d/topic/web2py/POYrBeZwvBk/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 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.
[web2py] Re: Design flaw in auth.impersonate ?
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 essential to see what the site looks like from their environment. On Monday, 6 April 2015 06:51:53 UTC+12, Louis Amon wrote: When you impersonate a user in web2py, your whole auth session gets replaced with the user's, and that means you lose access to whatever permissions you used to have ( http://web2py.readthedocs.org/en/latest/tools.html#gluon.tools.Auth.impersonate ) Practically : if you're a staff member (Support Team, not geek) and you're using a permission-locked back-office to impersonate a user, that means you won't be able to access the back-office to check for extra data until you impersonate(0) to go back to your own session and permissions. So far I've just asked my team to chew on it and just de-impersonate every time they need to go back to the back-office... but they keep complaining about it and they're quite right. I've been thinking about how to improve this, and so far I've only managed to narrow down a few options : 1. Building a second Session() object to manage both sessions separately 2. Using session.connect(masterapp=...) to use another application's sessions (between main app and back-office app for instance, if those are separate... which is a pain in terms of model management) 3. Messing with the permission system to add up permissions (staff member's permissions + impersonated user's permissions) before permission checks I'm really not sure what strategy I should adopt here and how I should go about implementing this. Pointers would be very welcome :) -- 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.
[web2py] Re: Design flaw in auth.impersonate ?
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 would see. So by default you only get the same permissions as the user you impersonate. this is not by design, and not an oversight. I see that sometimes you want something different. I guess the impersonate method could have an option that supports your option 3. On Sunday, 5 April 2015 13:51:53 UTC-5, Louis Amon wrote: When you impersonate a user in web2py, your whole auth session gets replaced with the user's, and that means you lose access to whatever permissions you used to have ( http://web2py.readthedocs.org/en/latest/tools.html#gluon.tools.Auth.impersonate ) Practically : if you're a staff member (Support Team, not geek) and you're using a permission-locked back-office to impersonate a user, that means you won't be able to access the back-office to check for extra data until you impersonate(0) to go back to your own session and permissions. So far I've just asked my team to chew on it and just de-impersonate every time they need to go back to the back-office... but they keep complaining about it and they're quite right. I've been thinking about how to improve this, and so far I've only managed to narrow down a few options : 1. Building a second Session() object to manage both sessions separately 2. Using session.connect(masterapp=...) to use another application's sessions (between main app and back-office app for instance, if those are separate... which is a pain in terms of model management) 3. Messing with the permission system to add up permissions (staff member's permissions + impersonated user's permissions) before permission checks I'm really not sure what strategy I should adopt here and how I should go about implementing this. Pointers would be very welcome :) -- 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.
