File editing is broken in panel

[seehat]

I get an "Unauthenticated" error when i open the file "last-tree-standing.jpg" in a fresh install of the starterkit on easyname.at hosting. I also get this error sometimes when navigating around in the panel. (similar to #1749 )

Steps to reproduce the behavior:

1. Go to 'Photography/Trees/last-tree-standing.jpg'.
2. Kicked back to homepage of panel with 'unauthenticated' error.

Kirby Versions 3.3.2

Console output

Server:

• Apache 2.4 with enabled mod_security, varnish, OPCache, open_basedir and default htaccess from starterkit
• PHP 7.3

Desktop:

• OS: macOS 10.14.6
• Browser: Chrome Version 78.0.3904.87 (Offizieller Build) (64-Bit) with enabled Browser Cache

Safari 12.1 and Firefox 68.0 are working and Chrome is also working, when I disable the cache in devtools.

[bastianallgeier]

Are you sure you are trying this with a fresh install of 3.2.0-rc.2 with empty cache? This should already be fixed. You can also try to disable the cache in the chrome console and check if it still happens.

[seehat]

Yes. I removed the media/panel folder and all cache files on the server and also in the browser.

It works when I disable the cache in the chrome console. But caching is normally enabled for visitors. Why does it work, when the browser cache is disabled?

[seehat]

Unfortunately the error also appears in 3.2.0.

[seehat]

The error appears in Chrome (Version 75.0.3770.100 (Offizieller Build) (64-Bit))

Safari 12.1 and Firefox 68.0 are working.

[afbora]

@seehat I cant reproduce this issue with Kirby 3.2.2 on Chrome 75.0.3770.100 64 Bit / Windows 10 Pro.

Could you test on fresh Kirby v3.2.2 install please?

[seehat]

Yes, I tested it now on a fresh install of Kirby v3.2.2 and it doesn't solve the Problem. It only appears on easyname.at hosting with Chrome and with enabled browser cache. It works locally.

Following modules/cachings are enabled on the server:

• varnish
• mod_security
• OPCache
• open_basedir

I have also tried to disable all of this modules, but then it also doesn't work. And it works in Safari and Firefox with all these modules enabled.

Is there something i can test?

Seems to be similar to #1749.

[bastianallgeier]

Hey @seehat! Sorry for the massive delay. Could you give it one more try with 3.2.5 before we move on with this?

[seehat]

Hey @bastianallgeier! No problem.

I tried it now with 3.2.5. Unfortunately it is still not working with the current version.

I've sent a mail on 13. August to kirby support with login credentials, that you can use for testing purposes.

[seehat]

Hey @bastianallgeier - Thx for the massive 3.3.0 update. Great work!

I've tried this with a fresh install of the current kirby starterkit. Unfortunately it doesn't work either.

Could you have a look into this?

[chaeringer]

Hello @bastianallgeier,

first of all thanks a lot for the great work you are doing with your team!

I can confirm this issue:

Hosting easyname.at (NO issues on localhost and with another hosting provider)

Kirby Versions 3.3.1

Chrome Version 78.0.3904.108

Everything works as expected in Firefox, Safari and with open devtools in Chrome.

[distantnative]

So this really seems to be an issue of easyname.at :/

[seehat]

I asked easyname and they don't have an answer for it.

I updated to Kirby 3.3.2 in the meantime... not working either unfortunately.

There is also an error when i open the following url in the browser:

https://kirby.e5-klosterneuburg.at/api/pages/photography+animals/files/free-wheely.jpg?view=panel

error:

{"status":"error","message":"Unauthenticated","code":403,"exception":"Kirby\\Exception\\PermissionException","key":"error.permission","file":"\/kirby\/config\/api\/authentication.php","line":10,"details":[],"route":"(.*)\/files\/([a-zA-Z0-9\\.\\-_%= \\+\\@\\(\\)]+)"}

This is the same error which gets thrown in the panel, when accessing a fileview.

[afbora]

@seehat could you share the a test app on easyname? I can look out.

[seehat]

@afbora I sent them to you. Thx in advance. :)

[distantnative]

Pinging @lukasbestle as this seems to be routed in sessions and CSRF.

[afbora]

@distantnative yes, i checked out and this issue about session/cookie. $_COOKIE global variable always empty on API side. ($_COOKIE['kirby_session'] should be return as filled on panel) So can't get session data while fetching file and unauthenticated error thrown. I tested with setcookie() in API methods and returns empty always too. When i disable cache from browser as @seehat said, working perfect. I wonder that cookies cachable?

[lukasbestle]

@afbora But it only affects that hosting provider, right? That's really strange – especially that it only occurs when the browser cache is enabled. That shouldn't change anything about the requests that do get sent, only that some requests no longer get sent as they are cached.

[seehat]

Yes it only effects easyname.at and currently there are following settings defined for this subdomain:

But it also didn't work with caching set to 0 and disabled.

[seehat]

I sent a mail to the easyname support and they told me, that they are having problems with scripts requesting cookies and they don't know why currently. So I think it is no kirby issue.

Do you have a suggestion, what I could do to bypass this? - or should I wait for an update of easyname? - In this case please close this issue.

[lukasbestle]

I‘m afraid this needs to be fixed by easyname as there is no way for us to handle the session if the cookie is not provided to the script. I don‘t know of a general workaround.

[afbora]

@lukasbestle I'd like to share with you the data I've reached to give you ideas.

Normal request header in panel:

array(20) {
  ["X-Varnish"]=>
  string(8) "53150523"
  ["X-Cache"]=>
  string(4) "pass"
  ["Surrogate-Capability"]=>
  string(11) "key=ESI/1.0"
  ["Cookie"]=>
  string(154) "kirby_session=5e2ab93003572a7eb8f63ae81c5de022217e5d1c%2B1576767994.760da85783d7ec7e5eb1.cb12d95144c8a162054bbd4779437ecdadd315450c3e61a2ae2b895d679769b9;"
  ["Accept-Encoding"]=>
  string(4) "gzip"
  ["X-Forwarded-Port"]=>
  string(3) "443"
  ["X-Forwarded-Proto"]=>
  string(5) "https"
  ["X-Forwarded-For"]=>
  string(13) "XXX"
  ["Host"]=>
  string(26) "YYY"
  ["Accept-Language"]=>
  string(23) "tr,en-US;q=0.9,en;q=0.8"
  ["Referer"]=>
  string(64) "ZZZ"
  ["Sec-Fetch-Mode"]=>
  string(4) "cors"
  ["Sec-Fetch-Site"]=>
  string(11) "same-origin"
  ["Accept"]=>
  string(3) "*/*"
  ["Content-Type"]=>
  string(16) "application/json"
  ["User-Agent"]=>
  string(114) "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"
  ["X-Csrf"]=>
  string(64) "70aa86a5ce1682136b32fdb6f519436ff7cc0279eb74f83795722d2c5f4355d9"
  ["X-Requested-With"]=>
  string(14) "xmlhttprequest"
  ["Dnt"]=>
  string(1) "1"
  ["Authorization"]=>
  string(0) ""
}

Accessing file request header in panel:

array(19) {
  ["X-Varnish"]=>
  string(8) "54558989"
  ["X-Cache"]=>
  string(4) "miss"
  ["Stored-Cookie"]=>
  string(154) "kirby_session=5e2ab93003572a7eb8f63ae81c5de022217e5d1c%2B1576767994.760da85783d7ec7e5eb1.cb12d95144c8a162054bbd4779437ecdadd315450c3e61a2ae2b895d679769b9;"
  ["Accept-Encoding"]=>
  string(4) "gzip"
  ["X-Forwarded-Port"]=>
  string(3) "443"
  ["X-Forwarded-Proto"]=>
  string(5) "https"
  ["X-Forwarded-For"]=>
  string(13) "XXX"
  ["Host"]=>
  string(26) "YYY"
  ["Accept-Language"]=>
  string(23) "tr,en-US;q=0.9,en;q=0.8"
  ["Referer"]=>
  string(99) "ZZZ"
  ["Sec-Fetch-Mode"]=>
  string(4) "cors"
  ["Sec-Fetch-Site"]=>
  string(11) "same-origin"
  ["Accept"]=>
  string(3) "*/*"
  ["Content-Type"]=>
  string(16) "application/json"
  ["User-Agent"]=>
  string(114) "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"
  ["X-Csrf"]=>
  string(64) "70aa86a5ce1682136b32fdb6f519436ff7cc0279eb74f83795722d2c5f4355d9"
  ["X-Requested-With"]=>
  string(14) "xmlhttprequest"
  ["Dnt"]=>
  string(1) "1"
  ["Authorization"]=>
  string(0) ""
}

As you will see, there is Stored-Cookie data instead of Cookie data on second request as failed. So $_SERVER['HTTP_STORED_COOKIE'] var exists instead of HTTP_COOKIE and that is like that:

["HTTP_STORED_COOKIE"]=>
  string(154) "kirby_session=5e2ab93003572a7eb8f63ae81c5de022217e5d1c%2B1576767994.760da85783d7ec7e5eb1.cb12d95144c8a162054bbd4779437ecdadd315450c3e61a2ae2b895d679769b9;"

[lukasbestle]

That's interesting. I have never heard of a Stored-Cookie request header nor can I find any information on it online. In case anyone has a hint for me, that would be great!

[afbora]

I couldn't find a single resource about Stored-Cookie on the internet too. Sorry @seehat but i think it has become clearer that this problem belongs to easyname.

[seehat]

I also think that its a problem belonging to easyname. I'm in contact with the support team. Maybe the find something. Thx for testing.

[seehat]

easyname has fixed this now . :)

[distantnative]

Yay!

[afbora]

@seehat Say hi! to easyname from us 👊 🤣

[seehat]

@seehat Say hi! to easyname from us 👊 🤣

I will. 😂

[manuelmoreale]

Jumping on this because this issue seems to also affect Cloudways and not just easyname. I'm currently facing pretty much the exact same issue (can't replace files) but everything else works just fine.

if I try replace a file I get an unauthenticated error and I then get kicked out.

Anything I can do to help you debug this issue?

[afbora]

@manuelmoreale Can you check the header of requests from browser console?

[manuelmoreale]

So apparently, in my case the issue was related to the Varnish cache that was turned on by default at the server level on Cloudways. Cache was not turned on in the Kirby config but apparently that didn't matter.

[bnomei]

So apparently, in my case the issue was related to the Varnish cache that was turned on by default at the server level on Cloudways. Cache was not turned on in the Kirby config but apparently that didn't matter.

same thing happend to me today on a new cloudways server. :facepalm:

[bnomei]

@afbora what i could find out was that varnish had cached the 403 repsonse from an unauthentificated api call to GET the file when clicking on the delete dialog. to reproduce...

• activate varnish
• fake an error by calling the api route in browser (this will cache a 403)
• upload a file to a page in panel
• use dropdown => api request (but with querystring)
• select delete => api request (without any querystring) like GET https://www.example.de/api/pages/2021+test-bruno/files/test.jpg => 403 status and will trigger a logout

maybe just provide at least one query string to ALL api calls since cache logics seem to cache these less often than wihout? maybe with a timestamp? GET https://www.example.de/api/pages/2021+test-bruno/files/test.jpg?api={{timestamp}}