Zend_Auth

The reason I say Auth is simple is because Zend Framework makes it simple with their Zend_Auth class. You can pick an auth style, implement and then go from there. For the purpose of this discussion, I'll be talking using Database authentication. So after one has set up a login page that uses Zend_Auth (there are already a lot of articles that cover this so i'll move on), the major bear you have to tackle is using the Zend_Auth_Result to determine proper access. Sounds simple, that's what Zend_Acl is for.

Zend_Acl

So how do we create our Acl? Again, ZF's reference guide gives us some handy-dandy examples of using their object but how you utilize the object depends on your scale. Other articles give you a way to bind the two together, usually via a controller plugin of some sort. The thing that can be tricky is how you want the Acl and Auth to interact with each other within that plugin. I utilize a controller plugin that fires off an Auth/Acl check in the dispatchLoopStartup() method. If no Zend_Auth_Result object exists, it assigns a guest role and if one does exist, it searches the Zend_Auth_Storage for a role value (assigning guest if one doesn't exist somehow) and checks that value against the Acl that was created in my Bootstrap. My biggest conundrum has always been translating Requests into Resources. I'll talk more on that later.

Scaling

I tend to put my scaling into one of the following categories: small,decent or ZOMG. Small is something like a personal site or a proof-of-concept/self-tutorial project where my users will probably be a 1-5 roles and 1-5 resources at best. Decent is most collaborative niche projects with 50-100 resources. ZOMG is where the number of resources I'm dealing with is >100, unknown or potentially large. I define my ACLs in my Bootstrap in one of three ways:

1. Hardcoded
2. As part of my Navigation Object properties
3. Pulled from a database

Hardcoded

This one is easy to implement since if you follow the ZF reference or the numerous guides/posts you find when you google for auth/acl systems, you'll be able to hardcode your ACL. I find this ideal for small projects where the number of resources is relatively low and the growth of adding additional resources is non-existent. This is the simplest way to do things.

Navigation-based

This method makes use of the Zend_Navigation object. Brandon Savage wrote up a nice guide to integrating ACLs into you r Navigation. I usually instantiate my Navigation objects in the Bootstrap from a XML file. The only tricky thing I found with this is finding the appropriate Navigation_Page (that tells us our resource/permissions) from the Request object. I tend to utilize this method when the growth of resources occurs at a slow pace.

Database-driven

This particular method is what spurred me to write about Auth and Acl. I see this solution as ideal for a high amount of resources or where the growth of resources to have fast spurts.  This solution can allow for ease of maintenance and is scalable. Even though it is a scalable solution, I kind of see it as overkill for smaller, low-growth projects.

Multiple project ACLs

Since I've began working with Zend Framework, I have used it to create both internal apps in addition to running my company's main site. To date, I have a total of eleven internal applications, some of which require Auth/Acl and some of which do not. Those that do not require them will soon be requiring them due to future features we wish to implement for them. At first I was working on a drag and drop solution for setting up an Auth/ACL system for any given project. I was going to work it a stand-alone module where all the developer has to do is call the Module Bootstrap within the Application Bootstrap. The drag and drop solution was going to rely on the project's Navigation object for determining the ACL of a requested page. Then it occurred to me that even if I could make this 'simple' drag and drop solution, we'd be faced with reapplying it to ten more projects and have subsequent setup processes for each additional project. This seemed highly inefficient and a pain in my ass.

Control Panel

My next realization was that there was multiple overlap on the users accessing various internal applications and way too many vhosts to make for each project. It seemed like it would be better to do the ultimate refactor and create a centralized control panel for people to authenticate and access internal applications.

I was still hung up on wanting to reuse my Navigation based code when I figured out that maintaining the navigation XML would be another nightmare. I had attempted a database solution for one project and it became a pain to maintain the ACL when I introduced Routing to the project. It was a bitter and hateful experience to get it working and since both the Auth/ACL and Routing parts of the project were done before I had embraced unit testing, sorting through my crazy monkey patching logic would only intensify my rage. I also recalled that the biggest issue with that proto-solution was translating the Request into a Resource.

In the schema shown on the right, the Resource.Name corresponded to the Request's Controller and Privilege.Name corresponded to Request's Action. When the ACL was created in the Bootstrap, it would create Module.Name_Resource.Name as the resource then associate privileges to that resource. Routing and Controller forwarding made this whole thing hard to mentally track. I ended up having a lot of monkey patch entries to make it work in the end.

So here I was, just generally damned when I thought up a way around the issues I had with the previous schema. I would need to have the Resource.Name independent of the Request URI in order to avoid routing issues. By associating the Resource to a URI, I don't have to account for if Routing exists or not. The URI will always be available and the core ACL system will be independent of any Routes that do/don't/might exist. Privileges bound to action seemed like a lot of overkill since all privileges come down to CRUD (though I always like the BREAD acronym better). In addition, privileges would be off in their own world and reused when necessary (the last schema had too many redundant privileges associated to different resources).

As I stated earlier, the goal is a unified login for internal apps (there are currently eleven and this number will grow). The user table consists of a username, password and control panel role. This role allows for future interfaces to be built that can manage the control panel such as adding a project or adding users. If you're wondering why I have the password column as able to be null, it's to support some legacy items. Next major table is the project table which lets me have a project_user table  that is also has a role associated with it. I made role a separate table since a lot of the projects overlap on roles such as guest and admin. Resources can be specifically named or generalized as necessary. All my links (URIs) can share a resource name if necessary. Finally there is the privilege table along with a resource_privilege table that allows me to maintain those relationships. While I have a separate control_panel_role, I decided that the control panel resource/privilege system doesn't need to be separate. I only wanted to make sure that the control panel system was accessible even if there was no projects available for selection. I'm planning on making the past projects into modules under this system and all future internal apps accessible/controlled from here. I lack any co-workers that I'm able to debate the merits of this idea with and given that this will be a major refactor of my work thus far, I am asking for feedback on the idea. Am I missing any other viable ways of defining the ACL that would be easier/better? I'm not a DBA so I'm wondering if my tables are actually optimized well enough. Any other issues or thoughts I haven't considered?

From my point of view, the discussion centered around what is the best 'default' visibility to use for methods. Another thing touched upon is the Open/Closed principle, which I think I subscribe to or may subscribe to(this depends on my ability to determine what half of the words in the entry mean).

Out of the whole discussion, here is the points I got (aka understood) out of it. Please correct me in the comments if I'm off base in any way.

Methods should only be public when necessary. This is to help reduce the amount of side-effects that can occur because of method overrides.

K, I can accept that and in thinking about my past code, I use to use protected more than private. I used public very sparingly.
Now I find, since I started unit testing, that I have a large amount of public functions than I've had in the past. That is because I can't figure out how to test private methods. One way that I can think of is to create public methods that allow you to test the private ones. Unfortunately, this makes me wonder why the method isn't public to begin with since it seems redundant and wasteful to have these public methods to access private methods.
Please note the key word methods, property accessors are a different story.
The best solution (I can think of) to testing private methods is Mock Objects. Unfortunately, even though I've started to use mocks/doubles more, I'm unsure if my implementation is correct. Until I'm confident in my understanding of mocks/doubles, I worry about having false positives in test results.

Another assertion that was made in the discussion was that private methods allow you to preserve the class' core functionality.
Unfortunately, no matter what the visibility of the method is, you're able to override it (and potentially mess with the core functionality you were trying to preserve).
Example:

class foo{
    private function foobar() {
        echo "foo\n";
        return "foo foo\n";
    }

    public function bar() {
        echo "w00t ";
        return $this->foobar();
    }
}

class bar extends foo{
    private function foobar() {
        return "bar\n";
    }

    public function baz() {
        echo $this->bar();
    }

    public function wut() {
        echo $this->foobar();
    }
}

$f=new bar();
$f->baz();
$f->wut();

By running the above code, you get:

w00t foo
foo foo
bar

If preservation of core functionality is your main concern, then you're better off using final.

So after all that rambling, you're probably wondering what I'm trying to get to. It still comes down to visibility's effect on inheritance. The way I see it, unless you declare the method as final, you can't lock down the parent functionality because private methods can still be overridden. Trying to figure out what level of visibility for a method is a situational call. There is no correct 'default' visibility. Sure private is safer because of least privilege but it makes testing a bear (or at least a bear at my current skill level in testing). Public potentially opens you up for abuse or misuse.

What I would still like to know is, how do you do class method visibility? How does that affect your testing methodology? Can someone give me an example (that isn't a singleton) where private is a better choice over protected? I like protected because it seems less limiting to me and my current coding style appreciates that degree of flexibility.