Why do almost no web frameworks provide any default authentication/authorization functionality, with default examples of best practices for common use cases. The standard response I've gotten for years was/is "well, everyone's needs for authentication are different". No, they are not. A (very?) large majority of web applications (which is what most web frameworks are used to build), require some form of user login and authorization management, and often self-registration, dealing with lost passwords, etc.

He points out that by not having something a user can immediately deploy that's been well tested and relatively risk-free, it can introduce security holes as a developer is "left to fend for themselves". He suggests that the "not everyone's the same" mentality that seems to go with authentication/authorization isn't as valid as once thought. He does point out that both Symfony2 and Zend Framework 2 come with ACL functionality, but no common user handling. He mentions ones in a few other tools used in other languages too like Devise in Ruby, Spring Security in Grails and a membership system in ASP.NET.

In this article I'll show you how to implement the Observer Pattern. You'll learn how various classes in the pattern relate to one another as subject and observers, how the subject notifies observers of a change in its state, and how to identify scenarios where it would be suitable to use the Observer Pattern in your own code.

The introduce the pattern by using an abstract "Observer" and "Subject" (that defines "attach", "detach", "getState", "setState", "notify" and "getObservers" methods) observer classes to coordinate the attached classes. They extend these classes with "Auth" and "Auth_ForumHook" show how to attach the "Auth_ForumHook" classes to the main "Auth" observer manager and change the state of the observer to notify it of an update.

You can find a more detailed explanation of the Observer pattern on Wikipedia.

On December 21, 2011 Stefan Koopmanschap wrote an excellent article on this blog titled "Painless (well, less painful) migration to Symfony2." [...] We were very much inspired by his passionate elucidation and we were fully convinced of the urge to start migrating to Symfony2 as soon as possible. However, he also provided us with a "A word of caution" about 2 things: performance and authentication/authorization. This might get some people worried, but not us: it challenged us to find a solution for those two open issues.

They explain why these two things are a problem and some of their solutions they've created - a .htaccess for routing and manually replicating the Symfony2 session in the Symfony1 code. Included in the post are the rewrite rules and code to make these two things happen (and a small configuration change to make them work).

This "client identifier" can be used by Oracle Database to distinguish between individual web application users who all connect to the database using one common set of database credentials. For example, every page in a web site might physically connect to the database as the same database user PHPUSER. If two different people 'Chris' and 'Alison' are using the site, these two user names can be set as their respective client identifiers and be passed into the database.

He shows how to set these client identifiers via the oci_set_client_identifier function (and how you could use it in older versions of the OCI8 driver too). He provides a sample application to help you get a good overall picture complete with SQL to load the database and a basic login page to submit and pull that data back out.

He moves over to the database side where he talks about enabling auditing, pulling out the logged application ID and how to use this identifier to restrict access via a Virtual Private Database on the Oracle side.

My tasks for 2008.2 were dedicated to the Webdav component. This package allows you to easily integrate WebDAV access features into your applications. With the earlier 2007.2 release, this component was born. By then, it supported just rudimentary WebDAV features (compliance class 1) and we focused on its architecture to make it as flexible as possible.

He explains how a commonly requested feature - locking - was implemented in the component. You can find out more about the feature/component in this article from Tobias on the eZ Components website.

There's not much more information than that in the main post, but several of the commentators are wondering if this will cause a delay for the next code release, if it will affect the Zend Debugger as well, and if it was an expected legal review.

There's no response yet from Guy Harpaz, the original poster of the thread, but we'll keep you updated.