[eluser]jedd[/eluser]
I think it is so dependent on the nature of your development team, the nature of the project, the standards you have in place, the sensitivity of your data, and your security model (how good your defence in depth approach has been).
For example:
[quote author="n0xie" date="1253378616"]
... your way, if someone 'forgets' to add the check, we'd be in a world of trouble.
[/quote]
My way, someone, and we - are all the same person in that sentence. It's unlikely that I'd 'forget' to put a security check in my template (it's already there) for new controllers, and it's unlikely that I'd not test this as a non-authenticated user before releasing anything to public view too. And when I say 'unlikely', I mean 'it won't happen'.
In environments with many people contributing to the codebase, and some of those people being the easily confused type, then inverting the logic might make more sense. If you tend to release your software to the world and wait for people to point out that, as an unauthenticated person, they don't have access to something they should (and they know this despite not knowing the thing exists in the first place due to the security defaults) rather than testing visibility of each component before release, then, again, I can see how this approach provides greater comfort.
I suppose part of my problem, too, is working out how you can have an authentication check in MY_Controller, that sends you straight to la-la login land if you're not authenticated, going straight past GO
and your destination controller, and yet .. and yet still somehow then allow access in some of your controller constructors (despite that code never being run).
