Site Blog

Plugins can now contribute email addresses to the bulk mailout facility.

A typical example is a name and address list (separate from your list of site members).

For coders, this is achieved by adding an e_mailout.php file to your plugin directory. There are examples in the event calendar directory (which is probably about as simple as you can get, and not very useful!), and the newsletter directory. The core mailout selector is also a pseudo-plugin file in the same format, and is in e107_handlers/mailout_class.php - this is a good example of a more complex file.

For users, you can configure which plugins are active - this helps keep screen complexity down. So if you don't normally want to mail your subscribers to events, just untick the box on the mailout options page.

One mostly for coders, here - and unlikely to be used frequently, if at all.

Although the log display normally shows times to the nearest second, all the system logs (admin, user, rolling) in fact store times to a greater accuracy. This will depend on the server, but at least 10-20ms resolution is likely, and microsecond resolution may be available.

The 'detailed' display option on the system logs display combines entries on all three logs, and displays time as accurately as possible. This allows you to see the precise sequence of events, and also exactly how long certain operations take.

Not sure how useful this is going to be, but if it wasn't there, we'd never know!

Mostly a tool for coders, this one. Its a separate log intended for events where you don't need a permanent record. So you can add debugging entries which write to the rolling log, for example - useful for those situations where echoing variables to the web page would cause problems.

Some anomalies detected by the core code also write to the rolling log - for example, combinations of values which shouldn't occur (and might therefore indicate a hacking attempt).

The rolling log can be enabled on the options page of the System Logs - and you can determine how long events are kept for. I find 7 days to be a good value to use - events are auto-deleted after this time, so your log won't grow for ever.

Banning users becomes quite popular sometimes. Especially on e107 websites that have a massive community, the chance on abuse is luring and inevitable. The v0.7 ways on banning were sufficient, but the devs recognized some improvements should be part of v0.8.

It is possible to create 'Ban Types'. Each Ban Type can contain an optional message that will be displayed to the banned user. Besides that it is possible to make 'internal' notes; that won't be displayed to the banned ones. Visitors can be banned on IP address, Reverse DNS, email or host address. Wild cards can be defined for any of these as well. To ban a user by user name, one can go to the users admin page. New functionality for a temporary ban has been introduced. Each Ban Type can be bound to an exclusion period, which can be set in hours, days, weeks or (of course) indefinite.

Besides the blacklist method it is also possible to white-list visitors; by doing so you can prevent certain users from being excluded to access of your website. White-listing is possible on IP address or e-mail address which are explicitly permitted.
The whitelist takes priority over the ban list - it should not be possible for an address from this list to be banned. All addresses must be manually entered. Of course a certain responsibility comes with this administrative function. It should be handled with extreme caution.

Furthermore in e107 0.8 the banlist has been extended with an interface for banlist import/export. It should become more easy to import existing banlists into your specific (starting) e107 environment. This opens the possibility for sharing community banlists, copying banlists between your sites, etc. All in all the new banlist provides some nifty features to even better protect your e107 website.

Just a quickie to start off the New Year.

You now have more choice as to how your users log in. Depending on how you set the options, they can now specify either user name or email address in the login box (how many of your users just assume the site'll accept an email address there?)

The alt_auth plugin is almost invariably the solution when you want to add users to your site by validating them against some other database. In 0.8 its had a major facelift, although some features will still be recognisable to those using the 0.7 version.

You can still validate users against various sources, including LDAP, Active Directory, eDirectory, and an alternative database - no change there, except that there are now separate menus for e107 databases and other databases.

There are two new authentication methods. The first is fairly straightforward - Radius authentication. This requires PHP's Radius extension to be loaded.

The second method is perhaps a little more difficult to follow, since it is used only when you have imported your users into the local e107 database from a 'foreign' system. The problem with importing users is often that the other system uses a different method of 'hiding' passwords - e107 uses MD5 encoding by default, some systems use SHA-1, and others use a variety of 'salted' encodings (see an earlier post for a description for this). A few systems even store passwords 'in the clear' - a jolly good reason for changing. Alt_auth can now check these passwords using a specified alternate encoding, and once validated converts them to the e107 standard. The support for other password encodings is also available when accessing external databases.

Historically alt_auth was intended to be used as a slave - the other system was the 'master' and you couldn't edit certain things (in particular, passwords) on the e107 system. You now have an option to set e107 as the 'master' system - so once a user has validated once against the other system, its not needed any more (for that particular user). That user can change things as normal on the e107, and doesn't care about the foreign system. Think of it as a pre-authorised list of potential users. New users can also sign up as normal, so potentially very flexible.

The other main addition is the ability to copy user information from the 'foreign' database into the e107 user record - both 'core' and extended user fields can be copied, and there are some conversion options which could fairly readily be extended.

Finally, setting up the connection has become easier - at the bottom of each method's setup page is a test area, where you can attempt to log on to the foreign system with a user name and password of your choice. The test feature returns a pass/fail indication, and on a successful test also shows the data which would be used to update the user information. So you can check out your settings without enabling alt_auth.

In conclusion, its not easy to test this kind of thing (and bits aren't fully tested yet); thanks to Father Barry and Cameron K for their help.

You'll be getting the idea that the userclass code has had a fair amount done to it for 0.8. It's probably not obvious from the name, but there are two ways in which permissions can 'accumulate' when using hierarchical user classes. Its important to understand the difference.

The first way we shall call 'organisational', because it mimics the typical structure of an organisation. You have the all-powerful being (CEO, Managing Director, God, or whoever) at the top, and beneath him or her a layer of managers, who have lesser managers beneath them.... This is achieved by giving the user class at the top of the tree (often Main Admins) a parent of 'No One'. Permissions then accumulate as you get higher in the tree, culminating in this 'all-powerful' class that has all the permissions of everyone below them in the tree.

The second way we shall call something else (suggestions welcome). Here the 'lowest' class is the ordinary site member, and permissions accumulate as you go down the tree. A typical use is to have different grades of membership, or memberships covering different specialities.

Another little feature is the idea of a 'group' userclass - quite simply a class which 'contains' a number of other user classes. For example, if you have a userclass to represent each country, you may wish to have a group for Europe, a group for Asia...

For those who like to see what happens under the hood, log in as main admin (on a 0.8 site, naturally), go to the user class admin pages, and manually specify the page yoursite/e107_admin/userclass2.php?debug. This will show you the tree, including the class numbers used, class numbers below each class in the tree, accumulated permissions and so on. It also lists the first 10 users with their 'raw' permissions, and the class permissions they acquire due to the hierarchy.

In common with many other systems, E107 currently stores passwords as an 'MD5 hash'. This is a 'one-way' encoding which makes it difficult to recover the original password, or one which will also work. For many systems this is perfectly adequate.

Needless to say, if you can recover the 'hash', it is possible to 'crack' these passwords given enough time and computing power. You can use the 'dictionary' approach, which works if the user has chosen a normal word for their password. Or you can use 'rainbow tables' (http://en.wikipedia.org/wiki/Rainbow_tables) - in principle, for each possible hash value you precalculate a value which will work as a password. This is a one-off operation. Cracking passwords then becomes a simple matter of looking up the hash in the rainbow table - much faster than doing lots of calculations.

0.8 gives an option to improve security by using a 'salt'. This salt (which is a text string) is combined with the entered password prior to calculating the hash function. The salt is different for each user, and is 'public' information (in that it is stored 'in clear' in the database).

This makes password cracking, especially bulk password cracking, much harder, since its no longer possible to use a standard rainbow table. Its necessary to calculate the rainbow table for each password you want to crack, which greatly increases the computing effort needed. So still crackable, but much harder to do. So hopefully any hacker will go and annoy someone else.

Salted passwords aren't needed by everyone - they do complicate password management in a number of ways. The option is there if you need it.

Sometimes you want to restrict or monitor the activities of a new user. You can do just that with the 'New User' class, which is one of the 'core' classes.

To activate it, set the 'New user probationary period' on the user admin options page.

Once set, all newly signed up users are automatically assigned membership of this class.
The 'new user' status is cleared the first time the user logs in after the probationary period has expired.

How you make use of this information is up to you - it may be as simple as doing more detailed monitoring of user activity.
Its another option available to plugin writers, too - you may give admins the option to restrict features to members of this class (which is named 'e_UC_NEWUSER')

Ever needed some basic site access stats - pages viewed, render time, maybe user info? Or an analysis of how consistent your server/host is?

0.8 has a simple option to give this.

Under 'Preferences, Advanced' simply enable 'Log all page accesses'

This creates a text file in CSV (comma separated variable) format in the e107_files/logs directory. One file per day.

At present information logged is: time/date, IP, page+query, render time, DB time, query count, memory use.

You can then import these files into a spreadsheet for further analysis in any way you choose.