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.
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. =(
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?
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?
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.
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.
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).