Posted by admin on Dec 4, 2008 in
joomla 有两款不错的反垃圾图片验证码插件
Bigo Captcha 图片验证码引擎插件
Bigo Captcha 插件是一个“验证码引擎”插件，可以为其它组件提供图片验证码。其特色在于生成的验证码图片具有动态波动效果。
例如，yvcomment 这个评论组件就可以调用本插件从而展示更漂亮的验证码图片。
上图展示的就是由 BigoCaptcha 插件生成的验证码图像，此处选择了长度为10，即显示10个字符。清晰易认。
OSTWigits Captcha 图片验证码引擎插件
插件是一个图片验证码引擎，它通过 freecap 库来为 Joomla! 1.5 平台提供验证码图片（captcha），并负责验证前台访客输入是否正确。
用户可以在后台选择是否只在验证码中使用来自字典（dictionary）的英文单词，这样可以方便访客识别。
本插件作为一个系统引擎，它最大的方便之处是其他第三方扩展开发人员不需要自己重新编写图片验证码的程序，可以直接调用此插件来实现反垃圾信息功能
Posted by admin on Nov 28, 2008 in
joomla Given enough time, that "ahha" moment eventually comes. The penny drops. The jigsaw puzzle starts to take shape. I clearly remember when I "got" MVC (Model View Controller) theory and realised my folly at being staunchly opposed to it.
The same can be said for documentation and, in particular, developer documentation. It’s a daunting task to work out how to organise hundreds of pages of information just about how you write code to work in Joomla!. We have five types of extensions, three types of applications, all sitting on top of a multi-layer framework involving hundreds of PHP classes and supported by over a dozen third party libraries. Making sense has been a significant challenge that has taken some lateral thinking to solve.
Enter the Wiki - some refuse to use them while others stare in wonder at the organised chaos as if looking at a representation of the Lorenz butterfly. This is one of the tools we are now using to address the enormous task of documenting all aspect of Joomla!. In this article, I want to spend some time going over how we have been structuring our sites to help developers find the information they need.
Posted by admin on Nov 27, 2008 in
joomla
By default, Joomla! allows access to your site using the built in username and password systems. For the most part this is fine. But, if you aren’t using this fea
ture, it’s good to disable it and remove any possibility of brute force attacks on your site. In addition, it is good to protect your site from others getting into the Administrator. Depending on the site you’re trying to run you might have disabled the front end Login Module and links, but you can’t disable access to your Administrator Login Form. Bummer! So we’ll work through this and give some options on how you can secure your Administrator to make it a little bit harder for the bad people to get in, but to begin with we are going to really fully disable front end logins.
Before we get started, I advise using a testing or development environment, maybe only on your own desktop, to test some of this out. As with everything, do not experiment with your production site.
1. Fully disable front end Logins
You might have disabled the Login module and removed all links to the Login Form but if you don’t want anyone to log into your front end you can take one more step to ensure that no one can login to the front end with the default install.
In the Administrator, navigate to Extensions -> Install/Uninstall, then select Components and disable the User Component. In my system, this option is towards the bottom of the list and it is also protected so that you can’t uninstall it. However, you can disable this Component which will prevent users from logging into the front end of the site and it will completely disable Registration. If you decide to use front end Logins later, simply re-enable this Component.
Following this process prevents users from getting directly to the front end Login Form via a link similar to index.php?option=com_user&view=login or index.php?option=com_login, if Legacy Mode is enabled.
2. Utilize Web Server Access Control
A great way to help secure your site is to implement another layer of security clearance before anyone can get to the Joomla! Login Form. This doesn’t need to be anything fancy or special, it’s just a simple level of protection. It is aimed at an attempt to slow down people who don’t know the password. It is a simple protection against direct file attacks in your Administrator.
What I’ll be covering is securing your site with Apache using .htaccess files primarily, so you must enable .htaccess for your site or set things up in the main Apache configuration. For flexibility, it is easier to enable .htaccess files for your Joomla! directory.
To secure your Administrator site you will need to create a password file. You can do this on most Linux or Mac OS X machines with the htpasswd command, and if you don’t have access to this then there are many generators online. Since this is a password file, you don’t want to place it in your web accessible directory, you will want to put it in a subdirectory.
You may also wish to apply access restrictions to the following front end directories as well: cache, tmp, modules, libraries, languages, and logs. You can do this simply by putting in a .htaccess file in each of these directories (or symlinked back to a common file, such as htaccess-deny in your site directory):.
Deny From All
This will prevent any access from the Web server to these directories. Some of these folders and files should not be accessed directly anyway, so, this extra bit of protection ensures that the folders and files are not accessed by anything other than Joomla!. Unlike the earlier setting, there is no username or password to get access to them either.
You may also wish to apply this to your plugins and includes directory as well, however this will cause issues with JavaScript and WYSIWYG editors. But, even this challenge can be resolved by individually unprotecting specific directories, such as the editors directory in plugins and the js folder in includes. The following line in a .htaccess file, or symlinked from a common file such as htaccess-allow, will allow access to those directories:
Allow From All
The Allow From and Deny From directives also accept IP addresses that you can then use to allow access or deny access to specific IP addresses, hostnames and wildcards. For more information on how to use these features, check out the Apache manual. So, if you’ve got Apache, you can do IP-based access control as well.
For more information, see Apache Access Control Restrictions.
3. Ban IP Address or Range
But, what if you can’t enable .htaccess or aren’t using Apache? In response to a posting on the Joomla! forum, a while back I wrote a plugin called Ban IP Address/Range for 1.5 that allows you to do the above, except from the Joomla! interface. The plugin doesn’t accept hostnames, however it does accept IP addresses and optionally ranges.
This System Plugin that can be configured to whitelist certain IP addresses (other addresses are blocked) or blacklist certain IP addresses or ranges from visiting your Administrator or your site. If you are deploying your site in an environment where access is restricted to a certain range of IP addresses, then you can use this method to limit access to your Administrator for only those IP addresses that fall within that range. You may also use this approach to limit access to your front end, as well, if required.
4. Implement jSecure
This is another approach one can use if Apache or .htaccess is not available, or to simply add another layer of security protecting the Administrator. jSecure is an interesting project that requires a user to enter a key before the Administrator Login Form appears. If the value is not entered, then a 404 page appears, instead.
jSecure is available for 1.0 or for 1.5 and is configured with a key to enable logins. This may be used as an alternative protection if you cannot enable .htaccess files. The extensions supports 1.0 via an Administrator module with a slight alteration to your Administrator template (if you are using the default, I suggest you make a copy of it and change the copy and then use the copy as the default template) or as a System Plugin for 1.5 installations.
5. Follow the recommendations on the Joomla! Administrator Security Checklist
The simplest is last, which is to work through the Joomla! Administrator Security Checklist to ensure that you’ve got your site running on the most secure settings available. The list might look long but it is well worth working through and trying to get things to work.
Also, remember that your site is only as secure as the Extensions that you install. Keep in mind that your hosting environment contributes to your security, as well. So whilst a lot of this can help your site, there are a lot of things that Joomla! can’t control that can cause your site to be vulnerable. Simply using good hosting will go along ways to protecting your Web site.
Tags: security
Posted by admin on Nov 26, 2008 in
joomla How to easily add additional data elements for Users
Written by Kevin Devine
The Usermeta plugin makes use of hooks in the JUser library to extend the properties of the user object. This would allow a developer to customize a user registration form to include information not available in the standard form. There are two different methods for extending the user object. The first is by adding to the user parameters which are stored in the params field of the jos_users table. The second method is by creating a database table joined to jos_users by a foreign key.
User parameters are defined in XML setup files which by default are stored in administrator/components/com_user/models. The UserMeta plugin provides an example custom XML setup file located in plugins/system/usermeta. A developer can use this file to define custom parameters for the user object then enable the UserMeta plugin to make them available through the hooks provided in JUser.
In the method JUser::getParameters() it is possible to define the directory path to XML setup files to be used for all user parameters.
JUser::getParameters( [ $loadsetupfile = false[, $path = null ] ] )
The second parameter of the getParameters() method is $path and by defining that parameter when statically calling the method the $parampath will then be defined as a static local variable in the getParameters() method. During subsequent calls to getParameters(), if the $path parameter is left undefined, the previous value will be used.
By taking advantage of the plugin trigger onAfterInitialise(), it is then possible, using a system plugin, to define a directory path to custom XML setup files where user parameters have been defined.
/**
* Define parampath as a directory path to custom XML setup files
*
* @return void
* @access public
*/
function onAfterInitialise()
{
// Enable the custom xml setup file to extend the user parameters
JUser::getParameters(false, ‘path/to/files’);
}
Once this plugin is executed the custom parameters are immediately part of the user object. If you choose to edit a user in the User Manager of the administrator you will see the custom parameters in the parameters box ready to be edited.
The one drawback of using this method to extend user parameters is that all of the custom parameters are stored in one database field. This makes it difficult to retrieve the data for other uses. The UserMeta plugin offers the option to extend the user object by using this parameter method or by using another database table joined by a foreign key.
Similar to the getParameters() method there is a getTable() method available to developers.
JUser::getTable()( [ $type = null[, $prefix = ‘JTable’ ] ] )
The method makes use of a static local variable to define which table class the application will use in building the user object. First the table class needs to be added to the JTable include path and then defined as the class to use in JUser. Again, this is possible by using a system plugin and the onAferInitialize() plugin trigger.
/**
* Define the table name of the user table
*
* @return void
* @access public
*/
function onAfterInitialise()
{
// Add the tables path to the JTable library
JTable::addIncludePath(‘path/to/table/class’);
// Set the custom table object as the user table
JUser::getTable('NameOfTableClass');
}
Obviously when using this method it is necessary to develop a custom table class capable of joining two tables. This is not possible using the current Joomla! framework but a custom class is provided in the UserMeta plugin which joins the jos_users table with a custom table named jos_usermeta. The fields of the jos_usermeta table can be defined by the developer installing the plugin. The plugin then dynamically reads the table information from the database and builds the user object.
It is possible to add these custom parameters and properties to both the user manager in the administrator and the registration form on the frontend. There are full instructions for using the plugin in a README file provided with the plugin.
Tags: joomla code
Posted by admin on Nov 25, 2008 in
joomla Joom!FreeMind 2.1.1 is a Joomla! 1.5.x native component. This extension generates an appealing visual mindmap observing your menus,categories and sections. It makes use of FreeMind - a premier mind-mapping software written in Java and displays the published site structure by connecting the component to a menu, a menu item or to a simple hyperlink placed inside your articles. The name of the component is the same as the one we have chosen for the stand-alone tool (you might want to check this one as well, especially if you are using Joomla 1.0) but note that the previous versions (1.8.x) do not provide complete Joomla! integration. Version 2.0.4 made corrections to the wrong categories and sections links. Several display options and color variation schemes were added in the backend, and Joom!FreeMind 2.1.1 kept the two different ways of rendering maps by either using the sections-categories structure or the published menus. It also brings the option of rendering maps through an alternative flash based viewer if you do not want to use the java viewer on your site.
http://www.xinet.ro/en/current-projects/joomfreemind.html
Posted by admin on Nov 24, 2008 in
joomla The Joomla Project is pleased to announce the immediate availability of Joomla 1.5.8 [Wohnaiki]. This release contains a number of bug fixes and two moderate-level security fixes. It has been around two months since Joomla 1.5.7 was released on September 9, 2008. The Development Working Group’s goal is to continue to provide regular, frequent updates to the Joomla community.
Download
Tags: joomla CMS 1.5.8
Posted by admin on Nov 24, 2008 in
joomla Each year Packt Publishing opens the voting booths for users everywhere to cast votes for the best content management system. There are a number of very qualified contenders in each of the categories including CMS Made Simple, Plone, and Drupal. This year, Joomla took the runner-up prize in the categories of Best Overall Open Source CMS Award and the Best PHP Open Source CMS (tied with CMS Made Simple). This results in a total prize winnings of $3500 to the Joomla Project.
Even though Joomla has taken home several Packt Awards in the past, Joomla Core Team member Andrew Eddie asserted, "This has made me more determined to do better next year."
Also, Joomla developer Johan Janssens was awarded the Open Source MVP 2008 prize, a new category in this year’s awards, for his outstanding contributions to Joomla.
We at the Joomla Project would like to thank all of our wonderful users to voting for us and a big congratulations goes to Drupal for taking first place in the Best Overall Open Source CMS Award category. We also want to congratulate all the other winners.
Joomla Core Team member Brad Baker summed it up, "The future is bright for open source content management systems like Drupal and Joomla, whichever you use."
