Also, the idea of centralizing the OTRS authentication has been discussed and rejected before: T133476: Proposal: Centralize OTRS login methodology. I proposed setting up an LDAP server years ago that would handle the authentication and role management, and the overhead was too high.

https://otrs-wiki.wikimedia.org/wiki/Greasemonkey_Scripts (Feel free to expand or rename) - I also ported to GitHub as opposed to the Paste, which was more maintainable.

In T263243#6475206, @Krd wrote:

Can you please put or link this somewhere on OTRS wiki? I think there are some more Greasemonkey scripts, at lease I have one that is a bit useful.

Hey, I don't know if this helps a lot, but I built a quick GreaseMonkey script that should restore the colors: https://github.com/Matthewrbowker/otrs-colors/raw/master/otrs-colors.user.js . This should work short-term until we decide what to do with our OTRS install.

In T122220#6473842, @akosiaris wrote:

In T122220#6471605, @Matthewrbowker wrote:

In T122220#6471256, @Krd wrote:

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

This is my biggest concern as well. My feeling, at least for the trial period, would be to require a post to [[AR]] on OTRS wiki. But, if we have to remove their 2FA token we also scramble their password and force them to reset it.

Long-term, we need a better solution (like a committed identity that enwiki has) - but all of that is taking more time from an already stretched thin admin team.

Another question/idea would be: How hard are OTRS modules to build? We could theoretically build an enhanced version of the built-in 2FA module, which allowed for scratch codes and hide the generator token.

A more suitable question would be "How costly are OTRS modules to maintain?" as I my experience up to now with OTRS modules is that most of their cost goes into maintenance and not building them. And since we would be probably patching the current implementation, it would be considerable. We would need to find someone to do build it and maintain it down the road.

In T122220#6471256, @Krd wrote:

I appreciate that we have that feature now and do test it, but I second akosiaris' statement above that we don't have any process yet to recover an account. I guess if anybody locks out themselves at the moment we could be unable to recover the account. Please consider that OTRS admins may not have enough resources for assistance at the moment.
If 2fa forces us to rely on anything not verifyable during account recovery, it perhaps doesn't add much additional security.

@DannyS712 Awesome, thank you for taking care of that!

I have also enabled 2FA on my account. It's a bit of a scary process currently - I'm used to being asked that 2FA is set up correctly by inputting a code. Instead, the interface just assumes that you're set up correctly, which makes it easy to lock your account.

+1 to the lab rat queue, I'd love to test this.

In T262399#6450086, @Cyberpower678 wrote:

Isn’t the edit counter supposed to issue a replay warning in these instances?

That's why I didn't tag any project admins yet, I wanted to open it for wider discussion from the XTools maintainers before I went ahead and implemented.

@MusikAnimal @Cyberpower678 Do we want to use the banner system to maybe add a message linking to T262239 on prod? Otherwise, I fear we're going to see multiple tasks related to this.

In T247900#5977553, @Zppix wrote:

In T247900#5977547, @Matthewrbowker wrote:

In T247900#5977515, @Zppix wrote:

In T247900#5977505, @Matthewrbowker wrote:

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

Why can't a trusted contributor without a wiki cloak be given the same rights as one with one?

Wiki contributors are vetted using OAth, requiring 250 edits, three months service, and no active blocks. I consider that pretty low bar, certainly not something would preclude someone who is hanging in our channels actively to achieve.

And if not, someone with a cloak can bangops. Or go to #wikimedia-ops and ask for help.

What about for example for users like myself, who meet those criteria for a cloak, but have a cloak with a different project?

In T247900#5977515, @Zppix wrote:

In T247900#5977505, @Matthewrbowker wrote:

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

Why can't a trusted contributor without a wiki cloak be given the same rights as one with one?

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

After some testing, this appears to affect all tools. Therefore, I'm putting the code into the User module rather than the GlobalContribs controller.

In T218485#5031203, @MusikAnimal wrote:

We could remove the hyphen and keep the parentheses, as you suggest, but I see nothing linguistically incorrect with the status-quo. I believe this presentation was the same in the older version XTools, so it's been around for years.

Hello, @Adithyak1997, thank you for the bug report. What exactly is the problem? Are you concerned about the fact that we put the word "Semi" in parenthesis? Are you talking about the word "HIde" which is in brackets? Or did I completely missunderstand?

A quick eyeball at the emails show it's a pretty standard "spoofing our email as a from address and reply-to address" spam. This happens about once every six months to a year but this is by far the biggest I've seen.

Since I did most of AdminStats, I’ll take this on.

And I've switched the instance to wm-bot, since that seems to be the standard in all of the tech channels.

I've set #wikimedia-tech and #wikimedia-dev to +rf #wikimedia-overflow. It's not an ideal solution but it is a solution, hopefully we'll be able to increase productivity in those channels. #wikimedia-overflow has a large op presence that can either invite users or solve the issues.

If you set a +r and +f, I would recommend #wikimedia-overflow, as it already has a topic with those instructions and a large chanop presence who can handle the messages as needed.

Actually, after further digging it appears to be related to Intuition. @Krinkle where would be the best place for us to request additions to language/mw-classes/Names.php?

It appears to be related to TranslateWiki, see message stats

Another option: Simply have wm-bot wait until it's identified before it joins channels.

From an initial look at things, looks like the database queries are timing out. This is probably related to the large number of revisions that AIV has.

I am assuming with the increased priority there is an increased urgency. As such, do we have a time-frame for when we want to upgrade to Symfony 4? I am ready to begin work on this as needed, we will need to coordinate roll-outs.

Saw the following in /opt/xmlrcs/nohup.out and restarted es2r.py. That seems to have fixed the feed, it immediately started reporting in #wm-bot again.

requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url: https://stream.wikimedia.org/v2/stream/recentchange
Traceback (most recent call last):
  File "./es2r.py", line 18, in <module>
    for event in EventSource(url):
  File "build/bdist.linux-x86_64/egg/sseclient.py", line 39, in __init__
  File "build/bdist.linux-x86_64/egg/sseclient.py", line 52, in _connect
  File "/usr/lib/python2.7/dist-packages/requests/models.py", line 893, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 502 Server Error: Bad Gateway for url: https://stream.wikimedia.org/v2/stream/recentchange
Terminated