A fun bit of trivia for the Joomla users out there from Brian Teeman's blog today - why the default user ID is 62 and how it could effect your site's security.

Andrew attempted to give the most complete answer but the truth is the answer is lost in the dim and distant past. There is nothing you can do about it. On every install a superadmin user is created with username "admin" and userid "62".

Since this is a common "feature" of the older Joomla installs, it could potentially be used in a sort of attack on the site. Fortunately, as of the Joomla 1.6 release, the installation allows you to select a username of your own (while still suggesting "admin") with a new change to the user's ID - 42 instead of 61.

On the Development Seed blog today there's a new post by Alex Barth about integrating OpenID support into your Drupal installation. You can check out an example of it in this github project.

After a survey of available single sign-on solutions [for a client], we decided to go with an OpenID based approach since we needed to support different domains, wanted to avoid sharing user tables and did not want to add complex system requirements for browser clients or the server. [...] The great advantage of this scenario is that we know which five sites need to play nicely together and all of them are Drupal sites under the client's control. This premise allows us to add an additional site as a designated OpenID provider that we call "Hub" and make all five sites point to the Hub as their default identity provider.

They use two modules to make everything work together - OpenID SSO and OpenID Provider SSO and a PubSubHubbub model for keeping the user information up to date.

In a new post to his blog today Sameer looks at a trick or two about detecting the type of browser/client a visitor is using to view your website - one method with the superglobal and another with a helpful PEAR package.

Every time you use your browser to access a website a User-Agent header is sent to the respective server. Detecting user agents on the server can be useful for many reasons: browser quirks, personalize content, preventing illegal access.

He talks about the get_browser function that's included in PHP but that requires a browscap.ini file to work. His other option is the Net_UserAgent_Detect PEAR package. It grabs the user agent and breaks it up into the browser type, operating system information and any Javascript-related headers that come along with it. There's also useful tests like "isIE()" and "isNetscape()" built into the package.

For most developers, working with XDebug is a simple matter of setting up the extension and getting to work. For larger teams, though, its not quite that easy. The way that XDebug is set up by default, it's no quite conducive to multiuser situations. Derick Rethans is here to help in his latest blog post, though. He describes a method (using a DBGp proxy) to handle splitting things between multiple developers.

As author of Xdebug, people ask me often the question how to handle the case in teams when there is one development server and multiple developers working on the same project on that server. [...] Now, in order to solve the above mentioned issue, you will need to run a DBGp proxy. DBGp is the protocol, designed by ActiveState and myself to facilitate communication between an IDE and PHP+Xdebug.

He walks you through the setup process - how to point XDebug to the correct location and how to configure the proxy to handle the multiple incoming requests and route the debug information back to the correct client.

WebReference.com has posted the next tutorial in their "user personalizaton" series - a look at the user's "home page" once they've logged in.

In this article, we will be looking at the home page of the application. This is the first page that the user will see after they have gone through the authentication process. The page will provide links and access to the rest of the application, except the admin section.

The code connects to the database, fetches all of the information about the user and their bookmarks. A table is generated showing the URL listing and the navigation is built. Also included it a bit of code to create a "recommendations" system.

Francois Zaninotto has a recent post looking at something every developer should consider when creating their applications - especially the libraries that might be used by other developers: code usability.

Usability guidelines can sometimes be of use in awkward places. I try to apply them to source code. [...] Of course, coding guidelines are there to make the code easy to read by everyone. But code usability goes somehow beyond. Let's see some of the differences.

He compares good versus bad code in a few different areas:

• Bad Code Comments
• Split Up Code
• Cleanliness
• New Conventions
• Listen To User Feedback

Each item is described, some including code examples to help make them more clear. Be sure to check out the comments for more good suggestions.

Keith Casey has a suggestion for budding (PHP) developers out there looking to jump head first into their first project: "Don't trust the users."

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world. They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads: Don't Trust the Users.

Generally, as Keith mentions, users aren't malicious/incompetent/ignorant 99 percent of the time, but there's always that off chance that they are and you need to protect you and your application from it by filtering input and escaping all output to prevent any mishaps.

In their final article in their "Introduction to CodeIgniter" series, DevShed has posted this look at how to create the views for their sample application. They'll output the user information pulled from a MySQL database.

In its current state, the structure of this sample application looked rather incomplete. It was comprised of a model and a controller class, where the first was responsible for retrieving user data from the table, and the second was charged with embedding this data in some view files, which actually haven't been defined yet. Therefore, in this final chapter of the series I'll be creating these views.

The new functionality they add into the application pushes an array of the user content into the "content" view. It loops through the records and outputs the first and last names as well as the user's email. Header and footer views are also included.

WebReference.com has posted the fourth part of their series on user personalization. This article focuses on the registration page for their sample application.

In this article we look at the registration script for our bookmark system. The script is basically responsible for admitting new users to our system. As you will see, it sets certain requirements that a new user must meet before they are admitted and also implements some data checking for security purposes, since it is going to receive a lot of 'outside' data that it needs to incorporate into the application.

The script takes in a username, password, email address and optional values for an image and a personalized color scheme. Some simple validation is done and escaping on the strings before they're put into the MySQL database. They also briefly mention some error handling that can be done by logging issues to the web server's error log.

Adam Jensen has written up a new article today on how you can use the Zend_Auth component of the Zend Framework to authenticate your users in a few different ways based on a strategy selected.

For this example, we're going to allow our users to authenticate in one of multiple ways: e.g., against a database table, against an LDAP server, or by OpenID [1]. Zend_Auth already provides the necessary authentication adapters, so what we'll be concerned with here is how to implement all three systems without ending up in an FSUC situation.

He defines the code for the basic controller and a simple view that allows the user to select how they want to log in - email/password, username/password or OpenID. The model does all of the heavy lifting by letting the controller set the authentication type (strategy) and pulling in the correct Zend_Form instance along with its validation rules. Code is also included for the model and each of these.