I am seeing a similar issue on our install:

One piece of minor mess here -- when you bin/auth recover yourself into a MFA'd account, you can get two MFA prompts: one to upgrade the session, then one to allow you to perform a password reset. Probably, the contextless password reset should only require MFA if you actually submit the form, and should do one-shot MFA, and ideally should carry the challenge tokens from the login and belong to the same workflow, although that's probably impractical.

Bind Challenges to Sessions

If you want me to look at something, file a report on Discourse with reproduction steps that I can follow to reproduce the issue. I don't need any other discussion or context. I do need working reproduction steps.

No.

@epriestley I have seen you working on Mercurial stuff. Can you take a look at my findings above?

Sorry, yeah, I meant T6703.

I believe that instead of T7667 you meant to write T6703.

This should learn from Auth and support multiple providers of the same type from initial implementation (see T6703).

I think we're going to fix this with T7667 instead. Binding to a particular domain creates headaches if you actually move the LDAP server, and unlocked authentication creates a lot of other problems that we can't address in a similar way.

This is conceptually easy but we have no outstanding requests from customers.

At this point, I don't anticipate this ever coming upstream. This is probably a good candidate for third-party maintenance after T5055.

This doesn't seem to be cropping up terribly often and I think this use case is fairly weak.

Presuming something fixed this.

This might happen eventually, or as a side effect of T7303, but the use case here is pretty narrow and there's currently no customer interest so I don't currently anticipate building it.

There are two flavors of this:

Password management is in good shape after T13043 , and this would now be fairly easy to implement in a general way by adding a check in PhabricatorAuthPasswordEngine->isUniquePassword().

There are probably some stragglers that have yet to turn up, but we appear to have survived this largely unscathed.

In T12145#242682, @joshuaspence wrote:

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

In T12588#242719, @epriestley wrote:

If any of these lists only have one form (or the user can only see one form), we'll take the user directly to the specified form.

When users click "Create Subtask", we now look for a list of possible subtask forms.

This is a great badge!

See D19829 for a followup change: getDetail()/setDetail() should be more-private APIs than they are today, and callers elsewhere (like transaction logic) should use methods like getEncoding(), not getDetail('encoding').

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

Ah, thanks! Yeah, that looks like the same thing. I think the bug title isn't quite correct (runtime is dramatically worse than O(input), but not infinite) and the analysis is slightly misleading (escaping the $ doesn't matter, I think) but the patch looks like it will get the job done (although, offhand, I'm unsure about the ($|(?=")|(?=\$) groups).

FYI, I think this upstream issue with pygments addresses this issue (was open since 2016, but only recently had a commit made to fix it): https://bitbucket.org/birkenfeld/pygments-main/issues/1257/infinite-loops-in-specific-files