Separate front & back end users

[sjadema]

Request

This is a feature request to separate the front & back end users. When developing and testing an application that requires logged in users or has a capability for logged in users it is quite annoying because the developer is usually logged in in the CP as well.

During development this is an annoyance but one can always visit the project in an incognito browser. It gets more annoying when using social logins (Facebook, Twitter, e.g.), because then you need to log in to those in the incognito browser as well. It also is a nuisance for the clients as they are usually logged into the CP as well and might want to test a social login feature on a staging environment.

This addition would separate the front & back end users in the session so one can be logged in into the CP and not logged in on the front end. A staging environment would benefit from this because it becomes possible to set the config setting isSystemOn to false so a tester would have to log into the back end to set enable the system but can still test different front end user scenarios.

Perhaps make it a configuration setting so projects relying on the old behaviour are still compatible.

[RitterKnightCreative]

Interesting suggestion. So when an admin user wanted to access the CP (but was already logged into the front end), it would ask for a login a second time as well? Could get confusing there...

Craft does have the accessSiteWhenSystemIsOff, accessCp, and accessCpWhenSystemIsOff permissions, not sure if you can work around your issues using that?

We usually just create separate testing users on staging. The social login features are tough to get right, no matter how you login.

[sjadema]

Well, when implementing the Commerce plugin it is quite annoying to have the admin account logged into the CP when developing checkout steps. The admin account gets coupled to a Commerce customer during this process which can lead to unpredictable test results. To avoid this i usually open an incognito browser to fix the registration process etc.

However, it is quite hard to explain to (non tech savvy) clients that they need to test those features in an incognito browser. Those permissions could help, but that would require them to log into the back end, e.g. a staging environment which has isSystemOn = false, and then uses the back end account as the front end account.

In addition to a config setting to preserve old behaviour, maybe it is possible to link front & back end accounts. In the same way a social login account is linked to a Craft user. I wouldn't know how to implement this user friendly GUI wise though.

For the application flow, one could use a polymorphic relation from a model implementing http://www.yiiframework.com/doc-2.0/yii-web-identityinterface.html to the actual user model attached to it. Depending on the request (front end or CP), the appropriate relation could be loaded.