Same problem while trying to upgrade from 1.38.2 to 1.39.0.

My confusion about the writeapi right was cleared by starting this topic: https://www.mediawiki.org/wiki/Topic:Vw6wwobg89cw970u

In T265043#6563578, @TheConen wrote:

It will fix one of the two reasons you're getting the 403 error - VisualEditor not only requires the writeapi right, but also the edit right. AFAIK, you still have editing disabled for unregistered users.

In T265043#6563578, @TheConen wrote:

It will fix one of the two reasons you're getting the 403 error - VisualEditor not only requires the writeapi right, but also the edit right. AFAIK, you still have editing disabled for unregistered users.

You were right that my initial assumption was wrong. Now I get:

In T265043#6563477, @TheConen wrote:

Yes, it does, as is explained on https://www.mediawiki.org/wiki/Help:ApiSandbox

Just create a test page and try to delete that one with the API

In T265043#6563436, @TheConen wrote:

which means that if I had defined these parameters (I didn't, because I don't want to actually delete any pages and I'm not sure if the API sandbox actually executes the requests) the unregistered user could proceed with the page deletion. Still there in no link for page deletion on the website, like it appears when I'm logged in, but it turns out the deletion could be completed through the API!

That is a false conclusion. The fact that the API tells you that you made an invalid request does not mean that a valid request would be allowed to execute. The API cannot check an invalid request for permissions (e.g. to delete a page) since it simply doesn't know what you want to do.

In T265043#6563419, @matmarex wrote:

In T265043#6563372, @CostasAthan wrote:

which means that if I had defined these parameters (I didn't, because I don't want to actually delete any pages and I'm not sure if the API sandbox actually executes the requests) the unregistered user could proceed with the page deletion. Still there in no link for page deletion on the website, like it appears when I'm logged in, but it turns out the deletion could be completed through the API!

No, it does not, you would have gotten an error if you submitted a valid request. Anyway, I don't care to argue with you about it.

In T265043#6562804, @matmarex wrote:

I don't think that raises any such questions. '*' corresponds to all users, logged in or logged out.

I suggested the second line for clarity, assuming you had some crazy permissions settings already. If it was confusing, then please forget I ever wrote it there.

If you are talking about the 403 error in my case that's the issue: T265043#6530768

In T265043#6548830, @matmarex wrote:

Sorry, I didn't read your comment closely enough.

I don't think you want to use $wgRevokePermissions here. Per the docs: https://www.mediawiki.org/wiki/Manual:$wgRevokePermissions "Revoking a right with $wgRevokePermissions takes precedence over granting it with $wgGroupPermissions. If the right is revoked for even one of the user's groups, they will not have it, regardless of whether it's explicitly permitted by other groups."

(As I understand it, the purpose of $wgRevokePermissions is to allow "soft-banning" users, by adding them to a group that has all or most permissions revoked.)

Assuming you want to allow editing for logged in users, but not logged out users, I think you want this instead:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;

In T265043#6548695, @matmarex wrote:

You can use the 'user' group to assign permissions to logged in users.

No, I did it.

In T265043#6530851, @TheConen wrote:

Well, you could have www.mywiki.com use Cloudflare DNS and www.mywikiwithoutcloudflare.com use your hosting providers DNS.

In T265043#6530823, @TheConen wrote:

Another thing that might work: set $wgVisualEditorFullRestbaseURL = https://DOMAIN_THAT_LEADS_TO_YOUR_WIKI_BUT_DOESNT_USE_CLOUDFLARE.com/rest.php

That way VisualEditor would bypass Cloudflare and you could use the IP solution with your servers IP address.

In T265043#6530807, @TheConen wrote:

AFAIK, VisualEditor is not part of any group, so you need to find a way to enable edit and writeapi for * - but only if the requests come from VisualEditor. The solution described in T263928#6518831 does this, but since you are using Cloudflare and every request comes from a different IP, even if it is sent by the server itself, this doesn't work for you.

You could try comparing for the User Agent instead of the IP - VisualEditor uses the user agent VisualEditor-MediaWiki/1.35.0, afaik. However, keep in mind that this would open a security risk - everyone with that user agent could edit your wiki, and user agents can be easily changed/falsified.

OK. I found it.

In T263928#6530632, @TheConen wrote:

Judging by the log you provided above, the IP address you need to use should be 162.158.73.250.

In T263928#6530558, @TheConen wrote:

In that case, you either need to apply the solution I described in T263928#6518831 or - if you are using HTTP only and no HTTPS - enable cookie forwarding as per https://www.mediawiki.org/wiki/Extension:VisualEditor#Forwarding_cookies_to_Parsoid. Keep in mind that if you enable cookie forwarding, you also have to manually configure Parsoid (https://www.mediawiki.org/wiki/Parsoid#Linking_a_developer_checkout_of_Parsoid).

In T263928#6530516, @TheConen wrote:

When you visit the site (/rest.php/[domain]/v3/page/html/Main_Page/95?redirect=false&stash=true) with your browser, do you get a JSON that tells you "rest-write-denied" or do you get a 403 error message served by your webserver?

Here is the log of the server:

Based on this solution that worked for @D3nnis3n, I modified my .htaccess file, which also implements short URLs, like this:

No, I haven't. What I'm going to look at first though is what is the equivalent of @D3nnis3n solution for Nginx for an .htaccess file for Apache.

As I'm not familiar with Nginx, do you have an idea what the equivalent code for an .htaccess file would be?

I also have set my wiki to what you mention as semi-private mode. That's probably not a coincidence.

I'm not sure if the solutions work for everyone. I tried both of @ssastry's suggested solutions and neither one worked for me. The .htaccess solution gives me a 403 error instead of 404.

Should I consider this as an answer to my question? RESTBase doesn't come packed along with MediaWIki 1.35, right? Even if it is so, according to the documentation the only problem that arises is the one with the "dirty diffs".

In T263928#6515101, @D3nnis3n wrote:

The wiki mentions it does only need to be installed if you don't want 'dirty diffs' to happen when switching editors. So it should still work out-of-the-box.
I mean i don't need it to work out of the box, but i expected a bit of a documentation on how to set it up - currently there is neither a documentation nor is it working out of the box.

Just a question. Parsoid comes packed along with MediaWiki 1.35. Does the same apply to RESTBase or should it get installed separately?

For me that code loads VisualEditor without the page's contents. I had achieved exactly the same behavior by just setting $wgVisualEditorFullRestbaseURL variable in LocalSettings.php

I don't think so. I always get the 404 error, not only with pages that have titles which contain specific characters.

Has anyone tried to recreate the problem?

Same problems for me too.

Something I would like to bring to everyone's attention: An extension that embeds gtag.js to MediaWiki offers two ways of opting out from Google Analytics tracking:

Hi @Aklapper. I was instructed in the past by @Florian to start a new issue in Phabricator about a feature request, which I guess falls in the enhancement category you mentioned, and I hadn't realized Phabricator has a limited spectrum of purposes.
Your message is noted, but I guess my question could be rewritten as a request for a simplified method of installation for those running their wikis in shared servers with limited control of the environment, if that's of course possible.

https://www.mediawiki.org/w/index.php?title=Topic:Vk6hsapb4n60rfzp&topic_showPostId=vk6r6ilrcag6paaz
User Ciencia Al Poder offered a solution.

That sounds impossible to do, as CookieWarning would need a way to intercept how scripts can be added and need to decide, if they should be loaded based on the consent given by the user, where the CookieWarning extension does not have any context to know that.

I added you by momentum. I guess adding someone to the subscribers is the appropriate way to go.