Lokal kein Zugang zum Installer, Panel und Login (de)

Hi!
Apologies for posting the bulk of this in German. I’ll try to post any follow ups in English. Thanks!
While some of the related and “similar” posts/issues I found in the forum, guides, or cookbook solved parts of my trouble (i.e. HTTP PATCH), the main problem still persists: no working installer, no login, no accounts.

Ich habe nach Jahren nun endlich mal wieder ein Kirby-Projekt in der Mache und es ist mein erstes mit Kirby 3!! Eigentlich freu ich mich schon drauf :wink: … wenn das Panel und Logins funktionieren würden.

Mein lokales Apache Setup läuft schon seit Äonen mit mehreren VirtualHost, da ich parallel an veschiedenen Projekten arbeite und so auch die Konfiguration der diversen Staging-Server etwas besser „emulieren“ kann (Docker oder VirtualBox gehen leider nicht).

Für diese Kirby3-Testsite sagen Apache (2.4) und PHP-Modul (7.3) unter Win10 Pro rv1909:

  • HTTP_HOST : kundenname.local
  • SERVER_NAME: kundenname.local
  • REMOTE_ADDR: 127.0.0.1

Eine Lizenz habe ich NOCH nicht für das Projekt, denn noch bin ich ja lokal am schrauben und wollte diese erst kaufen, wenn es auf den Staging-Server geht.

CMS und Panel sind per Composer installiert; alles Kirby 3.3.3. Zum spielen das Starterkit (abzgl. /kirby Ordner) manuell drüberkopiert.
Vorneweg: das Frontend mit dem Starterkit von Github funktioniert soweit tadellos.

Panel und Installer oder Login gehen aber nicht. Das wäre mir zunächst mal egal, aber der Kunde wird sich wohl irgendwann mal einloggen wollen…

Der Ärger fängt lokal schon beim Installer an (panel/install) und geht beim Accounts anlegen (per Skript) oder anmelden weiter.
HTTP PATCH ist eingerichtet und die fehlenden Dateien für admin und error hab ich inzwischen auch angelegt.

Bevor ich aber alle Schritte ausgiebig beschreibe, die ich bislang (vergeblich) unternommen habe erstmal die Frage:
Kann ich mit den obigen Server-Einstellunge (Hostname) arbeiten? Die IP ist ja lokal.
Üblicherweise haben meine VHosts diesen Aufbau
<VirtualHost 127.0.0.1:80 192.168.178.26:80> ... </VirtualHost>
damit ich auch von anderen Geräten im LAN (192.168.) auf den Apachen zugreifen kann.
In der hosts-Datei stehen diese lokalen Hostnamen/Domains auch jeweils drin.

LG

Regarding the frontend: Are really all pages accessible, not only the homepage?

How far do you get with the Panel? Does the installation form appear or throw an error? Anything in the browser console?

hi @texnixe
Everything in the frontend works fine.
I made some very elaborate tests with the panel, install and login. I documented the whole journey and my steps and tests in german though. I hope you don’t mind me posting that “report” below.

TL;DR: ran into the JSON / API error, fixed that and finally got this when I hit install:
Kirby Panel Login Install

The account files are created but login doesn’t work (grayscale PNG):
Kirby Panel Login Failed

Für Panel-Installer musste ich in der config.php 'panel' =>['install' => true] eintragen da ansonsten garnichts ging.

Mit 'debug' => false kam ich auch etwas weiter, da ansonsten PHP-Exceptions im Response Header auftauchten, z.B.

  • es gibt kein “admin.yml”, der Installer legt aber einen Admin Account an
  • es gibt keine error.php Template
    Die habe ich dann erstellt und es wurde stiller.

Dazwischen immer wieder Cookies und Sessiondateien löschen…

Nachdem dann auch das HTTP PATCH Problem (Apache 2.4) behoben war kam der Redirect auf

Alles eingegeben aber nur der leere “OK” Dialog taucht auf. Die Übersetzungsdateien für englisch weden aber geladen (gleich zweimal laut DevTools).

Im Ordner /site/accounts findet sich auch ein ge’hash’ter Ordnername mit dem eingetragenen Account.
Darin liegen

  • .htpasswd
    mit einem verschlüsseltem Passwort

  • index.php enthält ein Array
    return [
    ‘email’ => ‘die-email-adresse’,
    ‘language’ => ‘en’,
    ‘name’ => ‘’,
    ‘role’ => ‘admin’
    ];

  • user.txt 0 Byte ~ leer

Übrigens schmeisst Users::create() nach User->readContent() eine Exception, die Datei user.txt würde nicht exitieren (siehe unten).
Debug in der Config mal ein/aus, mal um weiterzukommen, mal um zu sehen wo es evtl. hängt.

Wie auch immer…
Rufe ich die URL http://kundenname.local/panel auf folgt ein Redirect aufs Loginformular http://kundenname.local/panel/login .
Das Form POSTed an http://kundenname.local/api/auth/login (Status 200)
Ein Anmelden mit der Mailadresse und dem Kennwort aus der Installation ist aber nicht möglich.
[Bild:Kirby Panel Login Failed.png]

Trage ich manuell in ‘name’ => ‘EinUserName’ ein und befülle user.txt zufuß gemäß admin.yml geht immer noch nichts weiter: kein Login möglich. Immerhin ist User->readContent() beruhigt.

Da mich der Web-Installer also nicht weiter bringt, habe ich dann nach dem Cookbook (https://getkirby.com/docs/cookbook/setup/migrate-users) einen abgespeckten Skript erstellt (ohne das Kirby 2 Zeug) und damit ein paar User angelegt:

$user = $kirby->users()
              ->create([ ... ])
              ->update([ ... ]);
$user->writePassword($user->password());

Nach ein paar Versuchen inspesondere mit update() hatte ich ein Paar neuer Accounts und es steht auch was in deren “user.txt” drin. Ein dump der User-Objekte sieht auch gut aus.

Zuerst wurde auch bei dem Skript gemeckert, dass kein Blueprint für die Rolle “admin” existiert.
Das stimmt auch. Im Starterkit ist keines enthalten, ebensowie kein error.php Template.
Dabei versucht das Starterkit selbst bei der Installation den ersten User mit der Rolle “admin” anzulegen (laut index.php im einzige User-Ordner).
Vielleicht ist das der Grund für obiges Fehlverhalten?
Egal. Auch wenn bei späteren Versuchen eine admin.yml vorliegt, geht der Login nicht.
Die habe ich aus dem default.yml User-Blueprint erstellt.

User werden nun zwar mit dem Skript angelegt, aber die schon oben erwähnte Exception wird ausgespuckt.
Pfade sind hier gekürzt:

 /site/accounts/Ba8jW9CZ/user.txt" does not exist in 
	www\kirby\src\Data\Handler.php on line 48

PHP Stack trace:
PHP   1. {main}() www\index.php:0
PHP   2. Kirby\Cms\App->render() www\index.php:5
PHP   3. Kirby\Cms\App->call() www\kirby\src\Cms\App.php:926
PHP   4. Kirby\Http\Router->call() www\kirby\src\Cms\App.php:296
PHP   5. Closure->call() www\kirby\src\Http\Router.php:107
PHP   6. Kirby\Http\Route->{closure:www\kirby\config\routes.php:34-47}() www\kirby\src\Http\Router.php:107
PHP   7. Kirby\Cms\Api->render() www\kirby\config\routes.php:45
PHP   8. Kirby\Cms\Api->call() www\kirby\src\Api\Api.php:576
PHP   9. Kirby\Cms\Api->call() www\kirby\src\Cms\Api.php:46
PHP  10. Closure->call() www\kirby\src\Api\Api.php:207
PHP  11. Kirby\Cms\Api->{closure:www\kirby\config\api\routes\system.php:46-76}() www\kirby\src\Api\Api.php:207
PHP  12. Kirby\Cms\Users->create() www\kirby\config\api\routes\system.php:68
PHP  13. Kirby\Cms\User::create() www\kirby\src\Cms\Users.php:31
PHP  14. Kirby\Cms\Form::for() www\kirby\src\Cms\UserActions.php:177
PHP  15. Kirby\Cms\User->content() www\kirby\src\Cms\Form.php:55
PHP  16. Kirby\Cms\User->readContent() www\kirby\src\Cms\ModelWithContent.php:74
PHP  17. Kirby\Data\Data::read() www\kirby\src\Cms\ModelWithContent.php:474
PHP  18. Kirby\Data\Handler::read() www\kirby\src\Data\Data.php:108
PHP Exception:  Missing handler for type: "" in www\kirby\src\Data\Data.php on line 70

Nun, die Datei “Ba8jW9CZ/user.txt” selbst existiert “irgendwann” ist aber wie gesagt 0 Byte lang.
Wenn diese Datei oder ihr Inhalt ohnehin optional ist, sollte IMHPO auch keine Exception geworfen werden, die den ganzen Ablauf unnötig stört (Header already sent). Oder die Datei sollte früher angelegt werden, damit User->readContent() nicht immer zwangsläufig ins Leere greift.

Aber all das nützt nichts, denn ich kann mich weiterhin nicht im Panel anmelden :frowning:

Gleichwohl scheint Kirby nicht damit einverstanden zu sein, dass es eine lokale Installtion ist.
Beim Login-Versuch steht dies im PHP Errorlog (Pfade und Timestamps wieder gekürzt):

 Exception:  The file "www/site/config/.license" 
	does not exist in www\kirby\src\Data\Handler.php on line 48
 Stack trace:
   1. {main}() www\index.php:0
   2. Kirby\Cms\App->render() www\index.php:5
   3. Kirby\Cms\App->call() www\kirby\src\Cms\App.php:926
   4. Kirby\Http\Router->call() www\kirby\src\Cms\App.php:296
   5. Closure->call() www\kirby\src\Http\Router.php:107
   6. Kirby\Http\Route->{closure:www\kirby\config\routes.php:34-47}() www\kirby\src\Http\Router.php:107
   7. Kirby\Cms\Api->render() www\kirby\config\routes.php:45
   8. Kirby\Cms\Api->call() www\kirby\src\Api\Api.php:576
   9. Kirby\Cms\Api->call() www\kirby\src\Cms\Api.php:46
  10. Kirby\Api\Model->toResponse() www\kirby\src\Api\Api.php:213
  11. Kirby\Api\Model->toArray() www\kirby\src\Api\Model.php:169
  12. Closure->call() www\kirby\src\Api\Model.php:127
  13. Kirby\Cms\Api->{closure:www\kirby\config\api\models\System.php:35-37}() www\kirby\src\Api\Model.php:127
  14. Kirby\Cms\System->license() www\kirby\config\api\models\System.php:36
  15. Kirby\Data\Handler::read() www\kirby\src\Cms\System.php:275

 Exception:  The file "www/site/accounts/.logins" 
	does not exist in www\kirby\src\Data\Handler.php on line 48
 Stack trace:
   1. {main}() www\index.php:0
   2. Kirby\Cms\App->render() www\index.php:5
   3. Kirby\Cms\App->call() www\kirby\src\Cms\App.php:926
   4. Kirby\Http\Router->call() www\kirby\src\Cms\App.php:296
   5. Closure->call() www\kirby\src\Http\Router.php:107
   6. Kirby\Http\Route->{closure:www\kirby\config\routes.php:34-47}() www\kirby\src\Http\Router.php:107
   7. Kirby\Cms\Api->render() www\kirby\config\routes.php:45
   8. Kirby\Cms\Api->call() www\kirby\src\Api\Api.php:576
   9. Kirby\Cms\Api->call() www\kirby\src\Cms\Api.php:46
  10. Closure->call() www\kirby\src\Api\Api.php:207
  11. Kirby\Cms\Api->{closure:www\kirby\config\api\routes\auth.php:25-44}() www\kirby\src\Api\Api.php:207
  12. Kirby\Cms\Auth->login() www\kirby\config\api\routes\auth.php:37
  13. Kirby\Cms\Auth->validatePassword() www\kirby\src\Cms\Auth.php:214
  14. Kirby\Cms\Auth->isBlocked() www\kirby\src\Cms\Auth.php:250
  15. Kirby\Cms\Auth->log() www\kirby\src\Cms\Auth.php:173
  16. Kirby\Data\Data::read() www\kirby\src\Cms\Auth.php:311
  17. Kirby\Data\Handler::read() www\kirby\src\Data\Data.php:108

Bin für Ideen offen.

First, a standard Kirby Starterkit will should work as it is, all files that are needed to make Kirby work are there, there is not need for an admin.yml blueprint (because that is a default role) or a specific error template or whatever.

An empty user.txt is also the default as long as you don’t create any user content. When you create an account, a hashed folder with a user.txt, .httpasswd and index.php are created.

Missing handler for type: "" in www\kirby\src\Data\Data.php on line 70

This rings a bell, I’ve seen this before and have to remember where…

admin.yml was required when I ran the cookbook script to create users with the admin role. the script wouldn’t run without a valid file present.
Still there’s an exception in that user creatiin process via install or via script that chokes on user.txt not existing, as you can tell from the backtrace.

If I navigate to “/panel/login” the crowser console shows:

SingleFile is hooking the history.pushState API to detect navigation. [ content-hooks-web.js:44:9]

Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen.

anything else are a bunch of .css and .js files with Status 200.

I don’t have time now to look more closely, will get back to you later if nobody else comes up with something in the meantime.

That’s fine. Thank you very much.
I can keep myself busy with the Frontend writing the new theme and create new content for the actual project. At some point I need access to the panel to fiddle with some plugins I plan to use.

Bei Fragen: fragen :slight_smile:

Cheers

What is really weird is that Kirby tries to read files that do no have to exist at all to make Kirby work: the .logins file, the .license file etc.

And it looks to me as if you started too many different things to solve the issue.

May I suggest you try again with a fresh Starterkit downloaded from GitHub (no composer, no nothing, just the zip and unpack in your project folder). Then try again to access your virtual host. Leave it as is, with debug enabled in the config.

1 Like

It’s not that I haven’t tried this before :slight_smile: That’s how this test setup initially began.

But why not?
Using this afternoon’s starterkit-master.zip (3.3.3), unzip, change DocumentRoot to point to the new location, restart Apache: same results.

The account folder exists but I can’t login. Console is “clean”.
However I didn’t do all the debug shenanigans as before.

I only later switched to the Composer setup hoping for a change and tried the steps mentioned above one after the other, tested, rolled back the setup etc. Tried another thing, searched the forum, guides, the interwebs etc. Took me two days intotal until I eventually “gave up” and came here 'cos “it doesn’t make sense” :slight_smile:

However, to repeat one of my initial questions: can I use the above hostname setup? Or will Kirby switch into some “unlicensed” mode that prevents access to the panel? I’m asking because of Kirby’s attempt to read a .license file.

Listen 127.0.0.1:80
Listen 192.168.178.26:80
...
<VirtualHost 127.0.0.1:80 192.168.178.26:80>
   ServerName kundenname.local
   DocumentRoot W:/bla/kirby
   ...
</VirtualHost>

I guess the attempt to read `.logins´ was due to a cookie or session files I forgot to wipe out.

Using “localhost” as the host name for web development is a no-go and will screw up my whole setup.

Thanks for you patience!

There is no such mode. Setting up virtual hosts shouldn’t be a problem.

Could you also please post the complete Virtual Host configuration? And your phpinfo?

That’s a buttload of text you’re asking for.
I zipped the conf and ini for you to download from my personal file dump:
https://depository.de/pub/Kirby3-nologin_17015.zip
[edit: I had to edit the files slightly for sensitive information]

Anything in particular in mind? Care to share your thoughts?

Enjoy reading :innocent:

I just set up a fresh vhost using the same starterkit (just unzipped it in the designated root folder) and your apache config with only few modifications regarding root folder names. Everything works out of the box. But note, on my system I have to change file/dir permissions in order for the webserver to write (creating a media dir in docroot and accounts dir in docroot/site folder). When I open kundenname.local/panel I was able to create a user and use the panel. I am on a linux system and do not know if file/dir permissions might cause issues on a Windows system, however I can only speculate that this makes the difference.

@Adspectus thanks for your test.
File permission are not the issue.
The folder has no ACL restrictions and both Apache and PHP can create/write/delete files.
All three files for a new account are actually created during the installation process (as described in the german part) as does the script I wrote to create some from scratch as outlined in the cookbook recipe.

This is strange, however at least your question

Kann ich mit den obigen Server-Einstellunge (Hostname) arbeiten?

can be considered as answered with “yes” :wink:

So, what’s left? You can create a user with password and language setting, hit “Install” and then, sorry to ask again, what happens?

when I hit install the empty dialog box appears (see screenshot above).
I then hit “OK” to dismiss this dialog and get back to square one.
Whether I reload the “install” screen or explicitly navigate to “/panel” or “/panel/login” I get the login screen, but can’t login (2nd image above). It tells me “Invalid Login” despite all account files exist.

While the login screen is open, PHP’s error log shows
The file does not exist at the given path: "bla/site/templates/error.php"
and The file does not exist at the given path: "bla/site/templates/error.html.php" respectively.

I also ran Firefox with a squeeky clean profile because: why not.
With the Login screen open, I now noticed this in the console:
"The JSON response from the API could not be parsed. Please check your API connection." followed by some backtrace for “app.js” and others.
The message keeps repeating; maybe due to some XHR polling or a rejected Promise.
I didn’t see this in my regular FF profile.

I remember this message only being shown once on the install screen in my early tests, but I got rid of it adding the HTTP PATCH to Apache. I have no idea what the culprit might be.

Nor do I. Your installation does funny things, looking for files that don’t (have to) exist for no obvious reason. But since we can’t come and visit you to have a look at your local installation, I don’t know how to help you.

One last try: Even though your provided apache config works for me, my first thought was it would not.

The problem I see is that you are defining some things on a global level, not within your VirtualHost section, where they should belong to. If you are doing this with your other hosts as well, it might cause unwanted effects. So the trouble might be not caused by configuration settings we see but with settings we do not see. For instance, I was wondering why you need Require method GET POST OPTIONS PATCH, but you will need it, if you have contrary settings on a global level before.

So I would suggest to check all of your apache config and change settings like this:

<IfModule mod_php7.c>
  php_value session.save_path W:/MPP/kundenname/tmp
  php_value track_errors Off
</IfModule>

<Directory W:/MPP/kundenname/www>
  AllowOverride All
  Options +Includes +Indexes
  <RequireAny>
    Require method GET POST OPTIONS PATCH
  </RequireAny>
</Directory>

<VirtualHost 127.0.0.1:80 192.168.178.26:80>
  ServerName kundenname.local
  ServerAlias cdn.kundenname.local
  DocumentRoot W:/MPP/kundenname/www
  CustomLog W:/MPP/kundenname/tmp/kundenname.access.log simple env=!dontlog
  ErrorLog W:/MPP/kundenname/tmp/kundenname.errors.log
  php_value error_log W:/MPP/kundenname/tmp/kundenname.php-errors.log
</VirtualHost>

to this (note the different nesting):

<VirtualHost 127.0.0.1:80 192.168.178.26:80>
  ServerName kundenname.local
  ServerAlias cdn.kundenname.local
  DocumentRoot W:/MPP/kundenname/www
  CustomLog W:/MPP/kundenname/tmp/kundenname.access.log simple env=!dontlog
  ErrorLog W:/MPP/kundenname/tmp/kundenname.errors.log

  <Directory W:/MPP/kundenname/www>
    AllowOverride All
    Options +Includes +Indexes
    <RequireAny>
      Require method GET POST OPTIONS PATCH
    </RequireAny>
  </Directory>

  <IfModule mod_php7.c>
    php_value session.save_path W:/MPP/kundenname/tmp
    php_value track_errors Off
    php_value error_log W:/MPP/kundenname/tmp/kundenname.php-errors.log
  </IfModule>
</VirtualHost>

In other words: Make all settings (and only these) which need to be applied globally (to ALL of your virtual hosts) on a global level and put your settings which belong to specific virtual hosts into their <VirtualHost></VirtualHost> section.

I have separate .conf files for each VirtualHost, client and projects in the working. They are loaded with a generic Include W:/MPP/APACHE/vhosts/*.conf at the end of Apache’s main http.conf and allow me to basically keep Apache’s own stuff as is.
There are other conf files to “fine tune” PHP’s behaviour or specific provider settings, but right now there’s only one file in that folder. I copied the “global” <IfModule mod_php7.c> for convenience with this test. For the most part error logs are actually off and if not, sit in a dedicated “webtemp” folder elsewhere.

The Require method is indeed overriding a (global-ish) setting that mimics some provider configuration where HEAD is disallowed. IIRC they do this to reduce sniffers and bots. I might check that point again though.

The <IfModule mod_php7.c> is actually superfluous.
I know the PHP module is loaded on my local machine, no need to test it :slight_smile:. It’s a relic from when I had to toggle between php5 and php7 settings. While all the php5 stuff is virtually gone, the IfModule somehow survived for it does no harm.

I might tidy up VirtualHost + Directory as you suggested, although that’s a very specific “access filter” on its own. There are no side effects of Directory being global or nested in a VH block. The paths always match the corresponding host’s DocumentRoot. This too is to mimic the situation of the production server as close as possible w/o affecting others. That’s how it works for me for +17 years now.

Sadly Kirby’s the only CMS that’s causing me these headaches.
Neither Wordpress, Joomla! nor TYPOlight/Contao, and even Typo3 had issues running in this environment. But I don’t want to use any of them for this.

I suppose I need to dig even deeper into this 'cos is utterly annoying. Maybe find some stray .conf Apache loads behind my back or a (hidden) .htaccess roaming around…

Still open for ideas.

Thanks.