Support

Site Restoration

#36922 JOOMLA backend cannot be accessed after kickstart restore to local PC

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

Latest post by nicholas on Tuesday, 12 April 2022 01:15 CDT

vbandke

Good evening from Germany :)

 

I tried to copy my love website (www.bandke.org) to my local PC (Win 10 pro) in order to try the migration to Joomla 4.  For this I did

  1. Install XAMPP (latest Version with PHP 7.4)
  2. Create a full backup of the live site and download the archive files to my local PC
  3. Copy the 3 kickstart fikes to the local document root and rename kickstart.php to restore.php
  4. copy the archive files to the local document root
  5. Invoke http://localhost(restore.php
  6. Did the full kickstart procedure, no error messages
  7. I chose for .htaccess to "USE DEFAULT", I can create a new .htaccess from the backedn using AKEEBA admin tools
  8. After "CLEAN UP" i could successfully access the front end and its menues, submenuesm etc

So far, so good.  But when I tried to invode the backend via http://localhost/administrator, after a somewhat long time the frontend was displayed, not the backend,  I truied again, and now a message was displayed

"System ist wegen Wartungsarbeiten gegenwärtig nicht verfügbar"

= system currently not available due to maintenance,

 

Of couese, this is NOT the offline message defined in my live site.  Also from now on I can no longer access the front end either, receiving the same message again,

 

I know, most of the errors are located about 70 cm in front of the screen, so plaease tell me what I forgot/overlooked/just plainly did wrong

 

With best regards

 

Volker Bandke

nicholas
Akeeba Staff
Manager

I need a screenshot of this error message. We definitely do not put any messages in our software in German; we only supply English language files since 2018. Trying to search for this exact phrase returns no results, so it sounds like you have set up on your site, most likely as the message for automatically blocked IP addresses.

Here's my theory of what must've happened.

Your original site is using Admin Tools with the administrator secret word feature set up. This means that you are accessing your site's administrator as something like https://www.example.com/administrator/index.php?YOUR_SECRET.

When you restored your site you said that you accessed the administrator as http://localhost/administrator without providing the secret URL parameter (which would've been http://localhost/administrator/index.php?YOUR_SECRET). As a result, you were blocked from accessing the administrator, a blocked request was recorded in Admin Tools and you were redirected to the frontpage.

Trying to do that again ultimately recorded enough blocked requests in Admin Tools that you got your IP address (127.0.0.1 since you're accessing the site locally) automatically blocked. So now you can no longer access your site because your local IP address is blocked from accessing your local site.

For some reason you do not remember that the message you are receiving is the message that you have set up as the blocked IP message and you sent us both on a wild goose chase.

You can confirm this by following the instructions in Admin Tools for Joomla! 4 :: Admin Tools' Web Application Firewall (WAF) locked you out of your site (akeeba.com) to get yourself unblocked from the local site.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

vbandke

Good evening, Nicholas,

 

your reasoning is sound, and mostly right on target.  Thus I could fix the issue.  The „secret word“ was enabled.  But I had set my home network fixed IP address in the exception list to be never disabled, and therefore didn’t need the secretvword when accessing the live site from my home.  Of course, my local IP network address was not in the exception list (neither localhost nor 192.168.1.xx).  Voilà - got myself locked out.

 

Thanks for the quick response and the helpful analysis!

 

With best regards

 

Volker Bandke

nicholas
Akeeba Staff
Manager

> But I had set my home network fixed IP address in the exception list to be never disabled

See, here's the misunderstanding :) There's something non-obvious about networking. For the benefit of people reading this public ticket I'll do a very short  crash-course into local networking.

All operating systems with a network stack come with a preconfigured virtual network interface called loopback. This creates a special network which exists only inside that operating system installation and typically has the IPv4 address space 127.0.0.0/8 (IP addresses 127.0.0.0 to 127.255.255.255) with localhost typically defined as 127.0.0.1 and the IPv6 address space ::1/128 (that's just the ::1 address).

When you restore a site on a local server running on the same machine as your browser you are telling your browser to access your site over the loopback interface. You can in fact disconnect all physical network interfaces (Ethernet cables, WiFi, Bluetooth etc) and you will still be able to do that. That's the whole reason of a loopback interface.

So, when you access http://localhost from your browser you tell it to go over the loopback interface to connect to your local server. Your local server sees the localhost IP address which is typically 127.0.0.1 (IPv4) or ::1 (IPv6). You can always set up your site to allow 127.0.0.1/8,::1 to allow loopback access without being blocked.

Why don't we add this exception by default? Two reasons.

1. It would prevent you from testing your changes in Admin Tools settings on a local server. If we had explicitly allowed localhost by default Admin Tools would be effectively disabled when developing a site locally. You'd be unaware of any misconfiguration which affects a live site. You'd deploy your site and everything would be broken. Oops.

2. It's a bad idea for live servers. Depending on the server configuration it's possible for a compromised site to attack other sites on the same server by doing HTTP(S) requests over the loopback interface. We don't want to give this kind of compromised site carte blanche to attack our site!

Now you know :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!