Symphony.

In my personal opinion not having a user system that can act for the frontend as well as the backend is not good enough.

It would be quite interesting to see the justification behind such a huge design decision. Isn't it easier to control the exposure of the user system on the frontend than not having it at all?

Are there any plans to implement this?

What are exactly the problems you see with this approach?
I personally think it is 100% inline with the symphony philosophy. Out of the box, it provides only a mean to access the backend, with basic permission management (author/developer). If you feel like this is not enough, there's a great extension that allows almost fine grained permission control over authors.

Sometimes it's fine to use the same auth system and the same user base on both backend and frontend – you can do quite a few things with just authors and a couple of events to enhanche the frontend.

In any other case, you should go with the member extension which is totally disconnected from the symphony backend and its users. The only problem I can see is the confusion generated by being logged both as admin (symphony dev) and as a member, but as soon as you realize there's no relation between the two, it will just sound right.

Maybe I totally missed the point, so please elaborate a bit more :)

What are exactly the problems you see with this approach?

Agreed, I'd be interested to see the examples of where you'd have wanted these to be unified.

One very good reason for them to remain separate, as alpacaaa says, is that Symphony provides the bare minimum so exposes the concept of "backend" users only. More often than not you don't need frontend logins in your site, so Symphony leaves this to a extension.

One issue I'd have with unifying the user accounts is security. One false click and you have the potential to accidentally provide anyone with access to your CMS.

Having an extension for this makes for bad ACL and an impaired permissions system *. Additionally someone has to wait to upgrade the extension to the latest symphony every time which hinders adoption by people who may need such a feature.

IMHO disabling the user system on the frontend can be managed to be as easy or as hard as the design of the feature and implementation allows it to be. While not having it at all makes the presence of such a feature, something that holds back adoption while the extension isn't updated.

Adding to that, since this is a matter of security, having a unified approach, tested and set in core, commonly used by all inherently guaranted higher level of security than an extension.

* Impaired permissions system refers to the flexibility, not in principle but in range of operations (relating to the frontend actions for example).

Having an extension for this makes for bad ACL and an impaired permissions system.

Actually, I believe the opposite to be true in this case: having ACL as an extension makes for a better permissions system. There will be circumstances when the ACL required by one’s site is completely different from what the Members ACL provides. Since there is no frontend ACL in the core, one does not have to worry about having to work around it or even (gasp) hacking the core files to bypass it.

Additionally someone has to wait to upgrade the extension to the latest symphony every time which hinders adoption by people who may need such a feature.

But this is true of all extensions, many of which provide features that are common and essential to certain types of sites. (How many of us can’t live without Subsection Manager?) Any time a new major version of Symphony comes out, there’s going to be a waiting period while the community updates its extensions.

Adding to that, since this is a matter of security, having a unified approach, tested and set in core, commonly used by all inherently guaranted higher level of security than an extension.

Why? The people who develop the Members extension are, in many cases, the same people who work on the core. Both core and extension are tested by the community, who are quite vocal about reporting (or even fixing) issues. Moreover, extensions are usually updated more frequently than the core. Hence, having ACL as an extension probably makes it more secure. ;)

I understand your desire for a working frontend ACL out of the box. It’s what we are trained to expect from other CMSes. But if one goes by what one expects from another CMS, Symphony, which is more like a framework, just seems weird. In fact, the first time I downloaded and tried Symphony, I ran far, far away! Now I can’t live without it.

The relationship between the Symphony core and its extensions is different from that of a traditional CMS. Symphony is designed to be extensible. The work that Nick has put into the Symphony Extensions site demonstrates that extensions are the heart of this community and the strength of Symphony as a CMS. More than that, I think the alacrity with which the community updated the most popular extensions for Symphony 2.3 demonstrate that this philosophy works well, at least in Symphony’s case.

There are no plans to unify frontend and backend users for Symphony, the reason simply being that we try very hard never to assume anything on the frontend of a site, so implementing a user system in the core would be a tedious job ensuring that it was powerful enough for everyone's needs.

Not all sites require membership, so having the membership system abstracted as an extension fits best with the Symphony philosophy. The Members extension allows us to move independently of the core (although point valid about updating as the core changes) and have greater focus on tasks (being separate repos).