The implementation of the mentioned security measures will impact export in such way that it wouldn’t be possible anymore for a user to perform an export just by accessing a bookmark links: users would need to go the UI and click on the export button.
I’m opening this vote for 1 week until 8th of september to ensure it’s ok for everybody to perform such break for security reasons.
Note that this applies to existing bookmarked exports and static bookmark links (like the ones saved in your browser). You will still be able to have a single click export but the link URL (that triggers the export) has to be dynamic (generated from a script).
That doesn’t look good from a user POV. Being able to export in a programmatic manner is needed. This is already a regression that happened with the client-side PDF export, as raised in Loading...
So -1 from me, unless there’s still some way to perform an automated export (without having to code something like a script in a wiki page).
It means being able to do an export with curl as we used to be able to do. See Loading...
Note that ideally I guess this use case could/should be implemented using a REST endpoint. So at the very minimum we need to be able to implement that REST endpoint to restore the lost feature.
Re Loading..., the reason it was important, back in the days, to have a URL that can be called directly was because we had no UI to be able to express all the query string parameters features we had. I believe this is still the case today so we still need to fulfill that use case too. Example use case: I want to export all pages starting with “Paris” in their references, and other conditions (see https://www.xwiki.org/xwiki/bin/view/documentation/xs/user/exports/export-page/pdf-customizations-url/ for the full list of options we had). EDIT: I don’t recall if we were supporting regexes/wildcards for the PDF export pages param as we had for the XAR export.
I guess one answer is to have some advanced section in the PDF export dialog UI for anything missing.
Now back to the bookmark thing.I still think there’s a UC problem. Imagine that I want to select specific pages, and specific parameters and then I want to give a link to a colleague that contains all these selected parameters/options. How can I do that?
In the solution we have in mind you could still do that, but the URL wouldn’t be enough: you’d have to specify another parameter for the CSRF token and/or use a POST to use that URL.
Being able to perform CLI-based exports is not in question here. The question is more if we think it’s OK to break existing CLI scripts by asking for additional information in the export URL (e.g. a CSRF token) or a different method (POST instead of GET).
An attacker could do the same. Make you click a link that triggers a large / unwanted export. It’s not easy / possible to determine if the current user intended to trigger the export or not, without having a CSRF token. If you can give the export link to a colleague, an attacker can do the same.
I guess it’s acceptable because of what it fixes. Needs to be in the RN ofc.
What’s important for me is the sharing of the export config. Could we share a URL and then it asks the user for a validation before starting the export? Re the attacker issue, if the issue isn’t protected (if the export action is not protected) then I don’t see how you would prevent anyone from triggering an export. I think we need an export permission for that. We can make it a bit harder by asking confirmation when the CSRF is missing for ex, no?
I suppose the export action could redirect to the “Missing CSRF token” page which would resend the export request (with the CSRF token) if the user confirms the action. Same as if you try to call the /save/ or /delete/ action without a CSRF token.
The goal (and what a CSRF token is used for) is not to prevent the action (save, delete, export, whatever), but to ensure that the user intended the action. On top of this we can add some limits to ensure the users don’t abuse the action. But the first step is to ensure there is intention.
It will need release notes for sure, but the trade-off seems acceptable as long as there’s a proper redirect to the retry action screen (for regular users). So +1 for me.
While I am not 100% convinced that the CSRF is the answer to the need in the quoted thread, here is my point of view for the export question:
Essentially, what I am seeing as a need quite often is the production and usage of a custom export link / button / path that allows to perform an export with predefined parameters, not going through the standard form / wizard that relies on the exporting user choosing the good parameters.
One more knowledgeable user (admin, dev, expert) is preparing these parameters and then they make the export path available to less knowledgeable users, that don’t need to ask themselves too many questions (any, actually) about the export parameters.
This can, indeed, be achieved in 2 ways:
indeed, with an URL (through the GET method) - which is what is currently being used / has been used historically to handle this need
with a form (through POST method).
You’re proposing to drop the first method and only keep the second (more or less).
The way I see this need most oftenly is for this export link / button / path to be shown on the XWiki UI (so the solution proposed by @mflorea would answer the need), but I cannot completely exclude the external URL, that @vmassol describes in his comments.
So, I believe that dropping the GET method could be acceptable (if there’s no other way), provided that:
any access of an URL that doesn’t contain all parameters still works, even if it ends up leading to an intermediary screen where the logged in user needs to confirm that indeed they want to perform an export. Of course, the values of the parameters from the URL are expected to be kept;
it remains possible to produce an export URL / form programatically, that would lead directly to the export, using the XWiki APIs, even if this URL would not necessarily be bookmarkable (an acceptable solution is that if such an URL is produced and bookmarked, when it’s used from the bookmark it would lead to the confirmation screen described above).
So +0, provided that the needs above are met (and the current proposal seems to be on the path to meet them).
GET will not work anymore unless the URL is generated dynamically
POST not be impacted
We don’t have rest endpoints to trigger export
I +1 this part
So +1 given my current understanding, and the fact that existing export URL still work, but with an additional user interaction to start the export (i.e., curl -XGET URL will not work, but visiting URL in the browser will work.