Support

OK, let's see, two things here.

First, the backups are always stored as archive files in your backup output directory (by default administrator/components/com_akeeba/backup). The basic premise of backups is that you can restore them even if your whole site has crashed in flames. It's very easy! Just copy the latest backup archive -tip: look at the file creation date- to your site's root, put kickstart.php in there and simply follow the instructions in the video tutorial.

Now, the other problem is with the databases. Since both sites store their data inside the same database with different prefixes, you have a slight problem: Akeeba Backup backs up the entire database unless you tell it differently, including the other site's tables. Just go to each site, use the Database Table Exclusion feature to exclude the other site's tables. Tip: you can click on the "Excluded non-core tables" button to have Akeeba Backup do that automatically. It takes a while (about 2 minutes), but it works just fine. Just remember to do that again when you install new software on the other site and you'll be just fine!

Yes, you have to exclude its database tables and its directory from the backup.

Hello Michel,

No, this is not true. Every time you restore a site, the new configuration.php file is written to disk at the end of the restoration. As a good security measure, the secret key is always overwritten with a new, random one. You have to manually edit it and replace the secret key with one of your liking for the single login to work.

IMHO, a login solution which is based on the secret key of all sites being the same can seriously compromise your security. I understand why this requirement exists (the login cookie uses the secret key to encrypt authentication information) but I can not endorse it as a secure way to handle single sign on in Joomla!. In the lack of a better solution, you can still use it but be aware that it's not a perfect solution.

Relocating the configuration.php IMHO offers exactly zero security and degrades your restoration experience (since the original configuration.php can not be backed up, the restored site will have lost all of its configuration.php settings, requiring you to manually reconfigure it after restoration).

The security implication of using the same secret key is that if an attacker intercepts or spoofs a cookie for Site A, then he will be able to use the same cookie for sites B, C and D as long as all of the sites share the same secret key. This can lead to a situation where Site A has exactly one exploitable vulnerability (e.g. in a component used only on Site A), sites B, C and D do not share this vulnerability, yet they are all compromised. If the attacker is wise enough not to touch site A, therefore not alerting you of the vulnerability he exploited, he will throw you to a witch hunt when trying to unhack sites B, C and D. He will be apparently able to login to those sites as if an act of magic, without any trace of vulnerability, misleading you into believing that Joomla! is insecure, whereas the truth is that you have an insecure component in the only site it wasn't attacked. In order to avoid this "black magic" race condition it is advisable to use a different secret key on each and every of your sites. Of course, that is incompatible with the single sign on feature as currently implemented on your sites.

In theory, single sign on should be performed in a quite different way. Ideally, upon signup, the authorising site could open hidden IFRAMEs to the other sites participating in the SSO (Single Sign On) scheme, with a cryptographically secured body containing the login credentials. This would allow the other participating sites to install their own cookies on the user's browser. While this doesn't absolutely shield you from the "black magic" race condition, a single captured cookie (e.g. of Site A) would not compromise the other participating sites. Of course, as is the case with singular authentication credentials shared between different sites, if an attacker manages to get hold of the username and password of a legitimate user, all bets are off; he would still be able to infiltrate all participating sites. However, the latter issue is inherent to any SSO scheme and is the security tradeoff for the convenience measure that SSO constitutes.

Thank you for your subscription!

Yes, in your case you don't have much choice but to endure the existence of two sites, unless you'd like to change your forum component (and have ample disk space). On this site I am using NinjaBoard. It's very fast all by itself, but the latest version has an even better feature. If you have caching turned on, it will pretty much cache everything, even SEF URLs (without even using a SEF component). If you have ample disk space, it will take a heck of a lot of load off your server, guaranteed. And, yes, it does import from Kunena. I'd suggest trying out NinjaBoard on a copy of your site first to make sure it meets your needs and consider making the switch. I've never regretted the switch and Stian, its lead developer, has been the most helpful (and then some!) every time I stumbled on an issue when occasionally using beta releases (the price I pay for using betas on a production site, I know, I know :D)