Problem:
Cache-Control conflicts with these changes.
When the user opens a slider, and later the page then they get the slider content instead of the page content.
I wasn't able to fix this with Vary
edit: fixed by appending value of X-Requested-With to Etags

also TODO: update docs so they say to use the X-Requested-With header instead of ajax parameter~~
edit: done

See also

I think we should start by forbidding the ajax mode for problematic cases. Moving to an HTTP header might not be necessary

See also

Yes I've seen it but there are too many files to change, so I left it for now
edit: done

I think we should start by forbidding the ajax mode for problematic cases

We can't do that because it's needed for the slider (unless we remove it)
Maybe just omit the cache on those requests?

One other approach is to disable the buttons in HTML and later enable them with JS, but it's not the best one.
edit: fixed, see above

@Alkarex Should I generate the .po files too?
It looks like they haven't been in sync for a while now

Now that po4a has a sufficiently high version on GHA I was hoping to automate something about that but I haven't found the time. A few years ago I'd have needed to add compilation or a custom Docker image which seemed like too much effort but perhaps that was a bad choice because of course everybody forgets or doesn't even know about it. :-)

Sorry 😓, but I am not so glad of this PR and would like to pursue an alternative instead:

• Improve security of form for user details #7771

My reasoning is that:

• A new HTTP header will break a bunch of existing FreshRSS deployments, many of which are behind a proxy that forwards only specific headers (see the numerous tickets we have had related to nginx, to the headers for the GReader API, turn-key solutions such as Yunohost, etc.). While acceptable if very needed, I would like to make efforts to avoid it.
• Buttons marked with confirm (at least if loaded from JavaScript) should be marked as disabled anyway until the JavaScript event that confirms when clicking on them is fully loaded / active.
• The current solution works (mostly) without JavaScript (using HTTP Basic Auth login), and this PR breaks (some of) that. While this is not a must have, I like to keep essential features working without JavaScript for a little longer (I have a plan for a parallel all-JS UI, for that is for later, and without removing the mostly-HTML UI)
• Not super important, but I am nevertheless not so happy of customising the http-conditional library with some non-standard conditions.

I hope that makes sense 🙈

That's fine, I do realize that my PR isn't necessarily the best solution given these circumstances.

Buttons marked with confirm (at least if loaded from JavaScript) should be marked as disabled anyway until the JavaScript event that confirms when clicking on them is fully loaded / active.

I think it would be a good addition to also require a separate "CSRF token" for AJAX requests, just as @Frenzie suggested before, to cover other buttons than those marked with confirm()

I think it would be a good addition to also require a separate "CSRF token" for AJAX requests

Yes, good idea. Help welcome