Is there another place not specifying the method for a form? I don’t think that attribute should be optional and instead the fix is to explicitly declare GET or POST or PUT for forms.

In discussion over a support ticket one of the potential options that was discussed was having a "An MFA challenge is about to appear, click to continue" prompt in the workflow as a means to prepare users to get their phones/devices ready so they can respond within the 30 seconds. Right now since MFA is opt-in per each user instead of required per auth portal - the current login workflow will immediately prompt you for MFA after successful login, which might surprise users who fumble to get the TOTP code out (it's happened to me).

The comments in https://secure.phabricator.com/T9770 discuss the "spyglass" attack and how this behavior is meant to be more secure.

nice

Very nice

Is it legit for this function to return an array instead of a single item? That’s the only structural question I have- everything else looks good and just some nitpicks.

Code-wise this looks good, though I’m not overly familiar with CSS or how Phorge uses it. Ready to accept after the empty icon thing is resolved.

This looks great! Thank you for working on it.

Just clarifying - this is for specifying the initial default value for the Default Branch field that can currently be edited after creation?

No worries, I haven’t had time to dig in. I wanted to review D25067

Thank you for clarifying!

I had discussed this with Evan previously and he gave a great explanation for why the current behavior exists, something he refers to as “spyglass attack”. I’d have to go back and review the explanation. What I recall the outcome being a few options, one of which was prompting the user that they are about to be promoted for MFA before issuing the challenge, to give the user time to prepare.

Thanks - the behavior I was seeing I think mirrors your own but the error I was getting was more directly related which confused me. It seems using @ does not clear the previous error from its use? Bleh.

I think updating the user script is a good idea if this functionality is needed.

I like this idea. A few things I want to note

1. Could you post a screenie for what the breadcrumb rendering appears as?
2. Does the name of this new class follow other classes that extend the hierarchy? I’m guessing yes but just want to double-check.
3. Maniphest tasks will render their primary Space (assuming non-default) as a prefix to the title. I think wiki docs should do similar.
4. Do wiki docs have a description field?

I wonder if there were plans to incorporate contact numbers with the prototype app for handling support (the name escapes me).

Something like this, though I'm not sure if this is actually correct - in PHP8 using @ will still throw a ValueError if passed an invalid encoding. But I'm not sure This @ thing is working as expected in php8, or I don't have a valid test case.

$message = null;
try {
  $result = @mb_convert_encoding($string, $to_encoding, $from_encoding);

I think this change is removing intentional design. The reason that @ is used instead of try/catch -- the comment on the function is saying if you have a string in e.g. Latin-1 and $to_encoding is set to something different-yet-valid such as Korean (e.g. ISO-2022-KR) -- then the encoding conversion will silently fail, not throwing an exception, but still populating the result with incorrect garbage. The exception only appears to be thrown if either of the to/from encodings are invalid like lol or asd. This is likely a breaking change.

Still accepted~

Do you think this also requires the strlen() check?

Thank you!

Thank you!

Similar here, on transactions it’s unclear if these are always strings, especially the use of the render functions. I think these should be null checked (for both vars, in both cases) and not use phutil.

Similar here it seems the values might not always be strings so should be null-check, and both old and new should be checked

For additional context the use of the phutil function would add the intent of the value being a string so my preference is to only use it if we’re sure the variable is intended to only be of type string. Here I think it’s less clear.

Correct, this change is what I was suggesting and not trying to continue if there’s no file data. If someone is calling the api to upload a file but doesn’t give any file data that’s a user/caller error and the server-side api execution has no sensible path forward.

Thanks!

I think !strlen(trim($var)) is more semantically meaningful than comparing to the empty string but this is fine. Locating calls to strlen which do not compare its return value to another value is more indicative of a non-empty check m, and easier to identify later on

Could you make these null-and-strlen checks instead? Notice that within the strlen check it uses “renderOldValue” instead of the old value directly, suggesting it might not be a string

I agree with a more targeted change of a git-specific argument if possible

Thanks!

These are likely fine. The reason for preferring null check instead is if there’s uncertainty that the values could ever be anything besides null or string. The nonemepty string check might reject something that was previously accepted, where an object that overrides __toString would have strlen and friends operate on the toString function but the object itself is still used/passed. In this case I think it’s likely fine.

oop

The "Create Identity" button on /diffusion/identity/ should be guarded by this new policy access, though currently that form is not functional - see T15453

Split to T15453

I mentioned in the diff but the "Create Identity" page appears to be incomplete and the issues here and while it uncovers some additional PHP-8 issues after addressing them the functionality of this form would still be incorrect.

I think there's another issue here. I don't think this functionality is fleshed out and not an issue with PHP 8.1/2. On this install and others I get 502 gateway when trying to use the Create Identity form. I tried playing around with updating PhabricatorRepositoryEditEngine::newEditableObject() so that it assigns the authorPHID (the field I initially see being reported as not allowed to be null) so it's the current viewer. After doing that I got another error about the identity hash not being allowed to be null. Because of this I don't think we should update getUTF8StringFromStorage() here and just expect this form to blow up for the time being.

What is being referred to as "Public Contents"? Wiki documentation? Diviner documentation? Ponder questions/answers? Other than those I'm not sure that should apply.

Taking a stab at what it would look like in D25276: Add support for secure connections to the database. It's not tested at all yet but I think that's roughly the shape it would take. I haven't looked into how this would affect cluster environments but I think that is covered.

Is a database migration needed to update existing installs or will the default just apply?

Yes. The trade off would be user experience. I have absolutely spent 15+ minutes waiting for a reset email on sites after having either typo’d or put in a different email address from the one I signed up with.

As an approach this seems good to me. Would it make sense to put creating identities behind the existing Edit policy of the repository?

I wonder if this is related to not being able to use the Diffusion repository file auto-complete when not logged in even though the repo is publicly accessible.

Could you check whether your install is running with this change? https://secure.phabricator.com/D21676

Arcanist internally generates a diff that includes a similar suggested parameter to account for the entire file contents being present in the resulting diff.