On enwiki you are not centrally logged in when you make an edit, on an IP masking wiki that needs to happen. I guess this is something we didn't have before - the login page does a cookie-based CSRF check so if you had cookies disabled you never even manage to login. But anonymous editing doesn't involve a CSRF check so the login process will fail in a later step.

What would be the expected behavior?

In T342767#9046516, @Tgr wrote:

What would be the expected behavior?

I'm not sure! From a user perspective I'd expect to either be told I can't edit with cookies disabled (as the typical user login form does) or for the process to fail more gracefully - i.e. my edit goes through but I'm not presented with an error message.

Do we want to prevent cookieless anonymous editing? It would break a lot of bots (which might or might not be seen as a bad thing).

In T342767#9226854, @Tgr wrote:

Do we want to prevent cookieless anonymous editing? It would break a lot of bots (which might or might not be seen as a bad thing).

@Tgr do you have a recommendation for what to do here? cc @Niharika

In T342767#10133701, @kostajh wrote:

In T342767#9226854, @Tgr wrote:

Do we want to prevent cookieless anonymous editing? It would break a lot of bots (which might or might not be seen as a bad thing).

@Tgr do you have a recommendation for what to do here? cc @Niharika

Sorry I missed the ping. Some things that come to mind:

• Get rid of anonymous edit CSRF tokens on temp user wikis. Pro: less confusing (users with no cookie support will just get a message about CSRF cookies), arguably more secure (cf T40417: MediaWiki's anonymous edit token leaves wiki installations (incl. Wikipedia) open to mass anonymous spam we can't block). Con: would need to create a session on the GET request, so more session writes (though probably not by much).
• Try to provide a more meaningful error to the user after saving the edit. SessionManager does not make it easy to differentiate between no session cookies at all vs. invalid session cookies. Maybe we should fix that. But it seems like a lot of effort for a minor use case so we could just change There is no active login attempt in your session. to There is no active login attempt in your session. (Maybe your device does not store cookies?) or something.
• Wontfix it. Seems like a fairly minor UX issue.

rMW366e55a990f1: session: Remember newly created secrets to fix Token::wasNew() fixed the equivalent issue for CSRF tokens, but since the token here is cross-wiki and can't use that, it's not affected.

Let's just do the i18n change, that's near-zero effort, then if someone feels strongly about this issue, we can figure out what else could be done.

The exact message is No active login attempt is in progress for your session. aka centralauth-error-nologinattempt. For central login we store a secret in the session and roundtrip it via redirect URL parameters, and this is the message when it's not there in the session at the end of the roundtrip. Maybe we could check if there is a (persisted) session at all and use a different message based on that. I'm not sure it's worth the effort.

@matmarex sorry didn't see you claiming the task. Feel free to pick a different solution (or non-solution) if you prefer.

Let us make the wording change at a minimum. It has come up on the talk page twice in the last week.

In general we should modify There is no active login attempt in your session to be more meaningful. I don't think it's clear what is meant by it.

Maybe something like: Could not establish an active session. This may be because your browser does not store cookies.

Does that make more sense?

Get rid of anonymous edit CSRF tokens on temp user wikis. Pro: less confusing (users with no cookie support will just get a message about CSRF cookies), arguably more secure (cf T40417: MediaWiki's anonymous edit token leaves wiki installations (incl. Wikipedia) open to mass anonymous spam we can't block). Con: would need to create a session on the GET request, so more session writes (though probably not by much).

@kostajh what do you think of this idea?

In T342767#11374419, @Niharika wrote:

In general we should modify There is no active login attempt in your session to be more meaningful. I don't think it's clear what is meant by it.

Maybe something like: Could not establish an active session. This may be because your browser does not store cookies.

Does that make more sense?

This sounds fine to me.

Get rid of anonymous edit CSRF tokens on temp user wikis. Pro: less confusing (users with no cookie support will just get a message about CSRF cookies), arguably more secure (cf T40417: MediaWiki's anonymous edit token leaves wiki installations (incl. Wikipedia) open to mass anonymous spam we can't block). Con: would need to create a session on the GET request, so more session writes (though probably not by much).

@kostajh what do you think of this idea?

I guess this would be easier to answer if we did some analysis into the risk vs the expected number of new sessions.

Shall we use this task for the message, and file a new task if we decide to do (or look into doing) the larger fix?

Focusing this task on the rewording. We can keep discussing the larger issue in T40417.

Change #1208301 had a related patch set uploaded (by Harroyo-wmf; author: Harroyo-wmf):

[mediawiki/extensions/CentralAuth@master] i18n: Update error message shown when the attempt info cannot be fetched

https://gerrit.wikimedia.org/r/1208301

Updating the i18n message here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1208301

Change #1208301 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] i18n: Update error message shown when the attempt info cannot be fetched

https://gerrit.wikimedia.org/r/1208301

This is only a change to a translation file, so moving this along.