Re: [Freeipa-devel] Integer parameters
On Mon, 2009-10-19 at 10:24 -0400, John Dennis wrote: > On 10/19/2009 09:12 AM, Pavel Zuna wrote: > > John Dennis wrote: > >> I wanted to assure myself if a command was expecting an integer value, > >> it could be input in whatever radix the user desires and be correctly > >> converted. If I understand correctly this code is in parameters.py and > >> is implemented by the _convert_scalar member function. The Int and > >> Float classes derive from the Number class and inherit > >> Number._convert_scalar which attempts to call the type (e.g. > >> constructor). However the int class only supports base 10 radix > >> strings in it's constructor, it will not do radix conversion. > >> Shouldn't the Int parameter class have it's own _convert_scalar which > >> invokes int(value, 0)? (Note: the second argument to the int > >> constructor is the radix base, with 0 being a special value indicating > >> the radix is to be derived from the prefix) > >> > > Int only accepts base 10. As you say, we could extend _convert_scalar > > and have it accept different bases. The question is, do we need/want it > > to? If we do, then it shouldn't be too hard to implement (and I > > volunteer to do it). > > Thanks, but I've already made the code change and it will show up in a > patch shortly. My main concern was this would alter the UI (accepting a > radix other than base 10) and I wanted to make sure this did not occur > without some discussion and/or awareness of the change. > > My personal feeling is the desired behavior for our interfaces is: > > * By default all integers are accepted as base 10 and presented in the > UI as base 10. > > * However to be friendly and to conform to some other external > conventions, it should be possible to supply a value in hex and have the > UI properly handle it. It's less clear to me whether the UI should ever > present an integral value in hex even if there is some president for > that particular value being presented in hex. > I think this sounds reasonable: allow int's to be specified in any base for which a Python literal repr exist (so I think that's base 10, 16, 8, and 2), but always display base 10 to the user. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 022 Change Password param
On Mon, 2009-10-19 at 15:14 +0200, Pavel Zuna wrote: > Jason Gerard DeRose wrote: > > This patch allows you do provide a Password as a two item tuple or list > > (the password plus the password confirmation). This is the most natural > > way for this to work through the UI. > > > ack. > > Pavel pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Integer parameters
On 10/19/2009 09:12 AM, Pavel Zuna wrote: John Dennis wrote: I wanted to assure myself if a command was expecting an integer value, it could be input in whatever radix the user desires and be correctly converted. If I understand correctly this code is in parameters.py and is implemented by the _convert_scalar member function. The Int and Float classes derive from the Number class and inherit Number._convert_scalar which attempts to call the type (e.g. constructor). However the int class only supports base 10 radix strings in it's constructor, it will not do radix conversion. Shouldn't the Int parameter class have it's own _convert_scalar which invokes int(value, 0)? (Note: the second argument to the int constructor is the radix base, with 0 being a special value indicating the radix is to be derived from the prefix) Int only accepts base 10. As you say, we could extend _convert_scalar and have it accept different bases. The question is, do we need/want it to? If we do, then it shouldn't be too hard to implement (and I volunteer to do it). Thanks, but I've already made the code change and it will show up in a patch shortly. My main concern was this would alter the UI (accepting a radix other than base 10) and I wanted to make sure this did not occur without some discussion and/or awareness of the change. My personal feeling is the desired behavior for our interfaces is: * By default all integers are accepted as base 10 and presented in the UI as base 10. * However to be friendly and to conform to some other external conventions, it should be possible to supply a value in hex and have the UI properly handle it. It's less clear to me whether the UI should ever present an integral value in hex even if there is some president for that particular value being presented in hex. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Re: [PATCH] Allow adding entries with pre-hashed passwords, but don't generate keys for them.
On Mon, 2009-10-19 at 15:06 +0200, Pavel Zuna wrote: > This patch only fixes the ADD operation - I'll make a second one for > modify > next. Just to make sure: If we allow admins to modify passwords with > pre-hashed > ones, we also need to delete kerberos keys (and possibly other > related > attributes) if present, right? Only KrbPrincipalKey I'd say. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 022 Change Password param
Jason Gerard DeRose wrote: This patch allows you do provide a Password as a two item tuple or list (the password plus the password confirmation). This is the most natural way for this to work through the UI. ack. Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Integer parameters
John Dennis wrote: I wanted to assure myself if a command was expecting an integer value, it could be input in whatever radix the user desires and be correctly converted. If I understand correctly this code is in parameters.py and is implemented by the _convert_scalar member function. The Int and Float classes derive from the Number class and inherit Number._convert_scalar which attempts to call the type (e.g. constructor). However the int class only supports base 10 radix strings in it's constructor, it will not do radix conversion. Shouldn't the Int parameter class have it's own _convert_scalar which invokes int(value, 0)? (Note: the second argument to the int constructor is the radix base, with 0 being a special value indicating the radix is to be derived from the prefix) Int only accepts base 10. As you say, we could extend _convert_scalar and have it accept different bases. The question is, do we need/want it to? If we do, then it shouldn't be too hard to implement (and I volunteer to do it). Pavel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Allow adding entries with pre-hashed passwords, but don't generate keys for them.
Fix bug #528922. https://bugzilla.redhat.com/show_bug.cgi?id=528922 Simo Sorce wrote: > On Thu, 2009-10-15 at 16:43 +0200, Pavel Zuna wrote: >> What Nalin said is exactly what I meant in my last email in this >> discussion (add >> -> hashed passwords fine, don't generate keys; modify -> hashed >> passwords bad, >> fail operation), but he explained it much better than I could ever do. >> I think >> that's the approach we should take. > > ack, > although I would also allow admins to always add pre-hashed passwords > even with modify operations. > > Simo. > This patch only fixes the ADD operation - I'll make a second one for modify next. Just to make sure: If we allow admins to modify passwords with pre-hashed ones, we also need to delete kerberos keys (and possibly other related attributes) if present, right? Pavel 0001-Allow-adding-entries-with-pre-hashed-passwords-but.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
