[PATCH 2/3] Fix issues in password validation. (#1014405)

David Shea dshea at redhat.com
Thu Oct 3 14:11:32 UTC 2013


On 10/03/2013 10:06 AM, Vratislav Podzimek wrote:
> On Thu, 2013-10-03 at 10:03 -0400, David Shea wrote:
>> On 10/03/2013 04:04 AM, Vratislav Podzimek wrote:
>>>    
>>> -    def _checkPassword(self, editable = None, data = None):
>>> -        """This method updates the password indicators according
>>> -        to the passwords entered by the user. It is called by
>>> -        the changed Gtk event handler.
>>> +    def _checkPasswordEmpty(self, editable, data):
>>> +        """Check whether a password has been specified at all."""
>>> +
>>> +        # If the password was set by kickstart, skip this check
>>> +        if self._kickstarted:
>>> +            return True
>>> +
>>> +        if not editable.get_text():
>>> +            if editable == self.pw:
>>> +                return PASSWORD_EMPTY_ERROR
>>> +            else:
>>> +                return PASSWORD_CONFIRM_ERROR_GUI
>>> +        else:
>>> +            return None
>>> A suggestion for some future patch -- could those checks return some
>>> constants? I see the same problem we had with the TUI input method here,
>>> those None and True says nothing about their meaning.
>> What do you think of having a set of string constants that the checks
>> use, kind of like the PASSWORD_EMPTY_ERROR and such in this last patch,
>> and a constant like PASSWORD_OK that's set to None? The underlying
>> mechanism where whatever's returned becomes an error message could stay
>> the same, but the return values would be a little less confusing.
> I think there should be something like CHECK_OK set to None and the same
> for True. All checks use the same return values (None/True/error_msg),
> right?
>
Yeah, that could work. The GUI checks are supposed to return None for 
OK, so, as far as that line up there that returns True: oops.


More information about the anaconda-patches mailing list