Deleting/replacing file from files section boots me out of panel

I have a strange problem.

On my xampp installation, everything works perfectly.

Once I upload it to my server, I can no longer delete uploaded files using the panel. I can create pages perfectly. I can upload new images perfectly. If I choose to delete the page from the panel, all the images included with that page are deleted with no issue.

But if I try to delete an individual image using the files section for that page in the panel, I get a window that says ‘unauthenticated’ and I am kicked out of the panel. This does NOT happen on my xampp installation.

A fresh kirby installation with the content/template/blueprints copied over does the same thing. Once again, zero issues running in xampp.

What could the problem be?

Have you emptied the media folder before deploying?
Have you tried to empty the browser cache and cleaned all session data and cookies from browser?

I have uploaded it to a new location. Deleted media folder and sessions folder contents beforehand. Used a different browser, so all cookies and cache are fresh. Created a new page and uploaded an image to it. When I try to delete a file I still get the unauthenticated error. =(

Note that I am also able to rename the file.

I just can’t replace/delete it.

And you are logged in as the same user and haven’t restricted file deletion for the user anywhere?

But honestly, I have no idea what could be happening. Since you are logged out of the Panel, somehow your session/session token is invalidated, it seems, when you try to delete a file.

Is there more information in the network tab for the request or the browser console, maybe?

I started from the plainkit. All users have admin rights. I have only ever used one user.

Console doesn’t seem to show anything when I get booted out of the panel.

Are you using the latest Kirby version, 3.1.3?

Have you tried if that also happens with a fresh Starterkit (i.e. non of your own content/code)?

A fresh install of the starterkit does the same thing.

Got booted when I tried to delete one of the default images (the fox). I run a Kirby 2 installation on this server with no issues. Is this some kind of incompatibility with Kirby 3?

I use a Cloudways VPS.

My steps:

  1. Upload starterkit
  2. Create new user
  3. Try to delete fox .jpg file using panel
  4. Got booted with ‘unauthenticated’ error

Are thumbs created in the media folder?

Yes, they appear to be:

Ok, the folder is writable. I’m running out of ideas. Maybe just create an issue on GitHub…

One more question: Is the file actually deleted despite the error?

No, the file doesn’t get deleted.

Only way to delete the file is to do it manually through FTP or to delete the page it belongs to.

Did you ever get to the bottom of this? I have started seeing the ‘unauthenticated’ error whenever I click images in the control panel, it flashes up then redirects me back to the panel homepage (which loads fine).

The issue was closed. Devs said it was a server config error on my end after struggling to fix it. Not sure if it’s true or not, but in any case I was forced to move away from Kirby for my projects. =[

Actually he just said it’s likely to be a server-sided error and it’s extremely hard to find out why it doesn’t work without access to the server in case of such problems. You could still talk to @bastianallgeier and find a way so he can do some tests on the server to find out what might be wrong as he did suggest in his comment.

Would be interesting to see what headers you receive…

We had a similar problem with easyname as hoster:

There it turned out that easyname was sending weird Stored-Cookie headers instead proper ones. Once reported to them, they fixed it.

Those issues are sometimes hard to debug as they have nothing to do with how Kirby works, but just false server setups.

I gave devs server access but they weren’t able to solve the issue. It’s not a complaint, just unfortunate. If anyone wants to give it another try at some point I can set it up again.

Using Cloudways to host.

As I said it would be interesting to see what headers you receive when the error occurs. Since we had the exact same problem with the roster easyname, there is the chance that it’s the same issue with Cloudways (and similarly easy to fix for them maybe).