Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Anti-Spam measures

We received an interesting comment in the site the other day about the anti-spam options that we incorporate into the Issue Tracker component.   The main gist was that Recaptcha was the only anti-spam option that we use.   However we had to reply that there were also other features such as word filtering, IP blocking, checks on the number of links, and the ability to ban specified email addresses and URLs.

We have (and still are) considering other options but do wonder whether it is the best approach to build all of these tools into a specific product such as Issue Tracker.   A typical Joomla site will have a number of components such as a Blog, a forum, a general article commenting system, etc., installed.   Other web sites even if not based on Joomla will have similar constituents.  Is it wise to have all of these parts with their own separate anti-spam measures?  The likelihood is that they will all adopt slightly different approaches with different measures of success, and all requiring updates to keep up with new techniques and methods.

Continue reading

Thoughts on the EU data protection regulation and Joomla

In January 2012, the European Commission announced two important pieces of legislation affecting the personal data of EU citizens: the EU data protection directive and the EU data protection regulation.  Of the two, the data protection regulation will have the greater effect on most businesses that collect, hold or share data within the EU. 

Continue reading

PECR– Cookies and Joomla Part 4

Several new product announcements to add to my growing list.  The JED now even has a separate section for Cookie Control

8. Cookie Choice is a non-commercial JED entry.  It does not block cookies but informs the user, which is what the current interpretation of the PECR regulations is understood to be required.

9. JE Cookies a commercial JED entry.  Details are a little light but it offers various colour options. 

One I have mentioned earlier 6. Cookie Alert does offer the country determination options, something we have in our own version.  We have tested our own version and it works reasonably well, although the impact on checking the country of origin on each screen refresh is something we are giving serious thought to, and would impact this product offering as well.

Our own home grown version is being tested and is working well.  One thing we have found is a small problem where if a visitor does not accept the cookies, and just leaves the banner displayed, continuing to browse the site, IF a separate modal window is opened, we have observed a situation where the model window is also presented with the cookie banner.  Not every modal window, just some, so we are investigating further. 

sh404SEF graphs, Akeeba Admin Pro and .htaccess

Just tracked down a configuration problem with the .htaccess file generated by Akeeba Admin Tools Pro which was causing the sh404SEF Analytics display to fail to display the generated site view graphics.

The problem was that the .htaccess rule was preventing the sh404SEF component from accessing the graphical data that it has created.  I could see that the graphical png files were being created but they were not being displayed.

Turning off the .htaccess effect by renaming the file, enabled the graphs to be displayed so it was obviously .htaccess that was at fault.

So then it was a case of finding the creation rule in the Akeeba Admin Tools Pro htaccess creator.

The solution was to add the directory to the list of exceptions:

Under 'Server Protection -> Exceptions -> '  add the path to the sh404sef_analytics directory to the list.

This then generates an exception which means that it is not picked up by the rule identified above.

Three Strokes and you are out

I have previously written about Spam entries on the web site and their elimination, but now I turn to 'Invalid Login attempts'.

I have been watching these with interest for a few weeks, and it is particularly interesting to see where they originate from.

Like the Spam entries a lot of these seem to originate from the Far East.  I am currently adopting a policy of immediately blocking 'Administrator Login attempts'.  No quarter given, I can think of no valid reasons why they should be tried by anyone other than those authorised to do so.

Turning to normal login attempts I have a policy of seeing how many different user names are tried from a specific IP address.  Once they have tried 3 different ones I immediately block them.  I must admit I am building up quite a long list.  Perhaps I should generate a graphical display of the souces, it could be quite interesting to see, and watch how it changes over time.

Given a single host country as being the source of a lot of these attempts, one could always block all the IP addresses assigned to that specific country but it does seem like 'using a sledge hammer to crack a nut' approach.  Possibly I will come round to that approach eventually.

The one single thing that I have not yet investigated is how accurate the IP address actually is.  Programs such as 'tor' generate anonymity of the IP address so do we actually know where they come from at all?  If its' use became widespread blocking of IP's might be a little bit of a waste of time anyway!


PECR-Cookies and Joomla Part 3

In my last post where I mentioned System - EU e-Privacy Directive I have carried out some tests and can confirm that it does indeed work very well. Code inspection reveals if is very light weight and tightly coded so should be very efficient on busy sites. Highly recommended. I note a newer version is also available so the author seems to be quite intensive in updating/improving the code and very responsive to reported problems and suggestions. It also supports Joomla 1.5 as well.

I have however decided to roll my own code and will shortly be releasing an update to our ‘Password Control Plugin’. The reasons include being able to store easily the cookie acceptance in the database, which means that even if the browser is configured to clear the cache when it closes (my personal preferred setting) it will still prevent the user being re=prompted every time. I can also add additional IP checks to check for the country of the site visitors, and also disable the banner display for ‘private’ IP addresses, within a company for example.

One discovery that I can confirm is that the basic Joomla front end works successfully without any untoward impact. Of course our site is not making use of compute intensive applications. I would add though that the same cannot be said of the back end which definitely requires cookies to work at all. [Note to self: Must never turn off cookies in the browser!]

New software announced for cookie privacy include the following:

8. PixCoookiesRestrict a commercial offering displaying the banner in the main page display area.

Blogging problem using WLW (Windows Live Writer)

Just found a small problem when using Windows Live Writer (WLW) as a blogging tool.

The situation is that for network reasons when WLW attempted to get hold of the blog entry on the server it failed yet still displayed the article.

Then when the article was changed and published it overwrote the original post, even though the title and most of the text had changed.   Never seen it do that before but will need to watch it very closely from now on in.

Now all I have to do is get back the original post from the backup.  - Never mind.

Seems it doesn't like it when you change destinations either for an entry, as it assumes that it is a new rather  than an edited old entry.


Problem remote posting blog entry with htaccess rule - resolved.

I recently implemented the strict htaccess rules generated by the Akeeba Admin Tools utility.   I then discovered that it was not possible to use Windows Live Writer to post entries to the blog anymore.   It was obviously a problem with the htaccess rules since a simple test removing the htaccess file enabled a post to complete successfully.

Looking at the configuration in more detail the most obvious cause appeared to be two rules related to access the xmlrpc directory:

RewriteRule ^xmlrpc/(index\.php)?$ - [L]
RewriteRule ^xmlrpc/ - [F]

But these rules permit access, they do not deny access. so they were obviously not the cause of the problem.

Then the light dawned.  There was a rule to redirect www addresses to non-www addresses:

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R,L]

Because the Windows Live Writer (WLW) blog account was set up before the htaccess setting were changed it was set up to use the ‘www.xxxx’ address NOT the ‘xxxx’ address.

For this reason the posting was being disallowed.   The redirection was getting in the way.  Just disabling this one rule enabled the posting to proceed.  It was desirable to have the rule in place, so once I had changed the WLW blog account to use the non-www address posting could resume and complete successfully.

I hope others find this interesting and perhaps do not spend as much time as I have trying to resolve it.

I thoroughly recommend Akeeba Admin Tools Professional as a user since it has stopped SPAM on the site almost completely.  That alone is a triumph.

Use of ampersand or not

I have recently been looking at the use of ‘Strict Standards’ and the impact upon any Macrotone written extensions.  One thing that has struck me is the use of the ampersand when making calls to JFactory (and other similar functions).

A lot of the examples on the Joomla documentation site show the call with the ampersand present, but it then generates a warning message if ‘Strict Standards’ reporting is turned on.

i.e.  Is it:

1.   uinfo = JFactory::getUser($user_id);


2. uinfo = & JFactory::getUser($user_id);

My understanding is that the ampersand after the equals sign is not required.  It was necessary to let PHP4 know that we wanted to assign a reference of the object to the variable instead of a copy. In PHP4 if the ampersand was not supplied it created another copy of the requested user information.   The default behaviour in PHP 5 is to assign by reference and using the ampersand produces a notice.  Joomla! 2.5  only runs on PHP 5, so the ampersand is not only redundant, it also throws a  strict notice.   I suspect that in PHP5 that if any extra instances are created by the use of the ampersand that they will be closed by the garbage cleaning when the containing function or class is closed, so apart from the Strict Standards warning message it is not really a problem at all.


PECR–Cookies and Joomla Part 2

Since my original post there have been several new developments announced, so this is to update my list of software:

1.  Name:  Kookie Grab   Website: JED

Notes:  An updated version announced  on the Joomla Extensions Directory, written by Kevin Griffiths.  Non-commercial it seems to have resolved the initial problems I discovered with it.

3.  Name:  Channel Computing   Website:  Channel Computing

Notes:  A plugin that displays a banner on the page.  A free lite version  and two commercial available.  This is the solution with have chosen to use (at least initially) as it minimises the changes required.   There seem to have been at least 3 updates to this software, some of which introduced problems along the way.  Still a very simple and clean solution.  

5. System - EU e-Privacy Directive

An extension by Michael Richey, which is non-commercial.  I have used some of Michae’s extensions previously and they all work very well.  Definitely worth a look at, especially if it does as claimed.

6.  Cookie Alert

A commercial offering, which I have not tested.

In addition there are several commercial offerings which seem to be appearing.  The Oracle web site used a product from Etrust which is interesting although probably over kill for most Joomla sites.

If you want to roll your own Portent have a free script code example.  Also worth looking at is Wolf Software which has a collection of scripts.  They do however store a cookie themselves even if you request no cookies, which somehow seems to defeat the object, and of course it all relies upon Javascript.

Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.