Przykład z książki

Witam, przeglądam sobie książkę Adama Freemana "ASP.NET Core 2. Zaawansowanie programowanie.".
Tak się zastanawiam tutaj przy jednym przykładzie metody Edit, w rozdziale z ASP.NET Identity:

[HttpPost]
public async Task<IActionResult> Edit(string id, string email, string password)
{
    AppUser user = await userManager.FindIdByAsync(id);
    if (user != null)
    {
        user.Email = email;
        IdentityResult validEmail = await userValidator.ValidateAsync(userManager, user);
        if (!validEmail.Succeeded)
        {
            AddErrorsFromResult(validEmail);
        }
        IdentityResult validPass = null;
        if (!string.IsNullOrEmpty(password))
        {
            validPass = await passwordValidator.ValidateAsync(userManager, user, password);
            if (validPass.Succeeded)
            {
                user.PasswordHash = passwordHasher.HasPassword(user, password);
            }
            else
            {
                AddErrorsFromResult(validPass);
            }
        }
        if ((validEmail.Succeeded && validPass == null) || (validEmail.Succeeded && password != string.Empty && validPass.Succeeded))
        {
            IdentityResult result = await userManager.UpdateAsync(user);
            if (result.Succeeded)
            {
                return RedirectToAction("Index");
            }
            else
            {
                AddErrorsFromResult(result);
            }
        }
    }
    else
    {
        ModelState.AddModelError("", "Nie znaleziono użytkownika.");
    }
    return View(user);
}

Chodzi mi o warunek if

((validEmail.Succeeded && validPass == null) || (validEmail.Succeeded && password != string.Empty && validPass.Succeeded))

Jeśli validacja emaila przejdzie, a walidacja passwordu będzie null to będzie ok?

Tak, gdyż prawdziwy będzie pierwszy człon, (validEmail.Succeeded && validPass == null), co czyni alternatywę prawdziwą.

lion137 napisał(a):

Tak, gdyż prawdziwy będzie pierwszy człon, (validEmail.Succeeded && validPass == null), co czyni alternatywę prawdziwą.

Tylko czemu tak? Do validPass jest przypisanie nulla, potem, jeśli string password nie jest pusty, jest do niego przypisywana walidacja. Więc jeśli validPass jest nullem, znaczy że password nie został podany, albo ja się pogubiłem.

Jeżeli parametr formalny password nie jest nullem lub pustym stringiem (z tego wynika, że metoda może przyjąć nulla lub pusty string), to jest walidowany, hashowany i przekazywany dalej; natomiast przeciwnie, ten nulll (validPass w tej chwili) przechodzi test w inkryminowanej linijce i wywoływane jest to:
IdentityResult result = await userManager.UpdateAsync(user);
Tutaj już nam nie Piszesz co się dzieje, być może tworzone jest nowe hasło.

Aaaa bo to jest Edit, więc nie musi zmieniać hasła jeśli nie chce. W takim wypadku, kiedy validPass jest null zmienia tylko maila? I wtedy to zostaje to stare hasło?

validPass jest nullem (i jest przekazywanmy dalej), wtedy gdy parametr formalny password jest nullem lub pustym stringiem. W obydwu jednak przypadkach (alternatywa) robiony jest, po czym wspomniałem update, który nie wiemy co robi.