Invalid CSRF Token on creating panel user

I deleted the user for the panel because I forgot my password.
I set the panel.install to create a new user but if i send my userform i got the error Invalid CSFR Token.
I don’t know whats wrong?


You probably just need to clear your cache, or reload the panel directly without any special stuff on the end. I think the session from your previous login is stuck in your cache. It’s something to do with submitting a previously submitted form again.

thanks. But I have tried to clear my cache also to restart my browser (Chrome).
Now I used the Safari to create my user. Here is everything fine.
After this I tried again to login me under Chrome. No chance. It notes that my email and password are wrong.
The must be something with chrome. On another Kirbyinstallation I have no problems to login. Very Strange.

Please try deleting your session cookie in Chrome and reloading. This should give you a fresh CSRF token.

PS: Does the error message really say “CSFR token”? It should be “CSRF”, but I can’t find that typo in our codebase.

Hi Likas,
Sorry the CSFR-typo was my mistake.
Delteing the session-cookie was the solving! Thanks.
I don’t thought on deleting t5he session.


i’m experiencing the same issue, but deleting session cookies doesn’t do the trick :confused:
any ideas on what could be the issue?

you could also try to use the Kirby Sessions
I found out that the Kirbysessions sometimes are in conflict with the normal php sessions.

thanks for the hint! i didn’t know these existed.
I’m not really sure how I would implement this as a fix for the login issue though…
do i just stick this


return [
    'session' => [
        'durationNormal' => 7200,            // default: 2 hours
        'durationLong'   => 1209600,         // default: 2 weeks
        'timeout'        => 1800,            // default: half an hour
        'cookieName'     => 'kirby_session',
        'gcInterval'     => 100              // default: cleanup every ~100 requests

into my config or is there more to it?

Yes, this set only a array session. With this you don’t set any session.
You can call this in your session-object as parameters.
With dump($kirby->session()); you can see what is in the global session object.
Please read the guide I have postet in my last post!
Further questions are welcome!


@bruno You don’t have to set these session config options in your config, those are the default values anyway, so unless you change anything , this won’t make any difference.

Do you set any headers in config? See this thread: Invalid CSRF Token on Hepburn Theme Panel Installation

no, config just has a specified URL value as well as panel install and debug enabled. No lines at the beginning of the file either.

.htaccess is vanilla plainkit. The files are on a subdomain though (, and although this has not caused an issue with other remote test sites on the same server before, I’m wondering if I need to modify the RewriteBase value in .htaccess for the install to work?

No, I don’t think so. The RewriteBase usually only needs to be changed on some servers when running Kirby in a subfolder, or be set to ‘/’ on some hosting (IONOS, for example). But in those cases, rewriting wouldn’t work otherwise, so without the RewriteBase set, you wouldn’t be able to access subpages.

Are you testing this with a fresh Starterkit?

Does this mean, other Kirby instances run without issue on the same server?

yeah, I learned this the hard way some time ago :~)

no, this is a project I’ve been working on locally & need to send to my client so they can upload things in a test environment before the site goes live… but I’ll test with a starterkit install.

yes! Or at least they had been until now? …Oh no, I’m starting to have the creeping suspicion that managed to fuck their servers up yet again… I’ll test the other sites

Ok, I think I have figured it out now.

For some reason, I thought

return [
    'url' => ''

was the correct way to install test sites on my server. If I didn’t configure it like this, nothing worked at all. So this is what I’d been doing whenever I needed to have a look at a test site remotely.

However I either never realised that I can’t access the panel this way, or some server settings have changed without my knowledge. Because what actually does the trick is – as you already mentioned – setting RewriteBase to /. The config file doesn’t actually matter at all, in fact, it breaks the panel if both RewriteBase and config file are set.

Thanks for your assistance…