[Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers

Rob Crittenden rcritten at redhat.com
Tue Mar 6 20:56:57 UTC 2012


Rob Crittenden wrote:
> Jan Cholasta wrote:
>> Dne 18.1.2012 00:04, Rob Crittenden napsal(a):
>>> Jan Cholasta wrote:
>>>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a):
>>>>> Rob Crittenden wrote:
>>>>>> Jan Cholasta wrote:
>>>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a):
>>>>>>>> When viewing a certificate it will show the serial number as hex
>>>>>>>> (dec).
>>>>>>>>
>>>>>>>> # ipa service-show HTTP/rawhide.example.com
>>>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM
>>>>>>>> Certificate: [snip]
>>>>>>>> Keytab: True
>>>>>>>> Managed by: rawhide.example.com
>>>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM
>>>>>>>> Serial Number: 0x403 (1027)
>>>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority
>>>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC
>>>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC
>>>>>>>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69
>>>>>>>> Fingerprint (SHA1):
>>>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6
>>>>>>>>
>>>>>>>> rob
>>>>>>>>
>>>>>>>
>>>>>>> NACK
>>>>>>>
>>>>>>> Displaying a host or a service in the webUI fails with "IPA error
>>>>>>> 3009:
>>>>>>> invalid 'serial_number': Decimal or hexadecimal number is required
>>>>>>> for
>>>>>>> serial number".
>>>>>>>
>>>>>>> I would suggest to do the nifty formatting of serial numbers on the
>>>>>>> client side, that would fix the webUI issue, allow non-IPA
>>>>>>> clients to
>>>>>>> parse the number without dissecting the string representation of it
>>>>>>> and
>>>>>>> probably also save me a hack in the type conversion overhaul. You
>>>>>>> could
>>>>>>> for example add a parameter flag like "format_serial_number" to
>>>>>>> indicate
>>>>>>> to the client that it should format the value as a serial number.
>>>>>>>
>>>>>>> Honza
>>>>>>>
>>>>>>
>>>>>> Well, we want to do as little client formatting as possible. The
>>>>>> idea is
>>>>>> to have a very thin client.
>>>>
>>>> It doesn't seem right to me to enforce this specific representation of
>>>> what is really just an integer at the API level. Doing a little
>>>> formatting on the client side won't make the client(s) particularly
>>>> fat,
>>>> will it?
>>>
>>> Yes. The current code just outputs labels and data. There is no "if it
>>> is this attribute then do that" logic.
>>>
>>>>
>>>> IMHO there is too much stuff done on server that would make more sense
>>>> to do on client anyway (especially CLI-specific stuff such as CSV
>>>> parsing). What is the reason we want such a thin client?
>>>
>>> To avoid double work such that every time we want a formatting change we
>>> have to change it in multiple places. This lesson was learned in v1.
>>>
>>>> I believe there should be clear separation of presentation and content,
>>>> but perhaps I'm a little bit too idealistic :-).
>>>
>>> You have a point, serial number is defined as an integer. Perhaps we
>>> should revisit this decision to display hex at all.
>>>
>>>
>>>>
>>>>>>
>>>>>> I'll look into fixing the UI side.
>>>>>
>>>>> I don't see this error in services, it displays correctly. I'm not
>>>>> sure
>>>>> if it is my browser or what but hosts don't display much of anything
>>>>> for
>>>>> me.
>>>>>
>>>>> rob
>>>>
>>>> I have just checked both master and ipa-2-2 and I'm getting the same
>>>> error message (tested in Firefox 9.0.1) when viewing details of a host
>>>> or a service with the usercertificate attribute set.
>>>>
>>>> BTW, wouldn't it make sense to format serial numbers in the cert plugin
>>>> in the same way?
>>>
>>> Perhaps. Like I said, I'm not really in favor of this change.
>>>
>>> rob
>>
>> Maybe we can do a compromise of some sort. What about allowing the
>> client to specify with each request what representation/formatting the
>> server should use for the resulting entries and attributes?
>
> That would be mighty flexible but would open a new can of worms. I think
> long term I'd like to be able to request what attributes to see (ala
> ldapsearch) but that too is a bit out of scope.
>
> This comes down to Output being rather loosely defined and we already
> have a ticket open on that. It basically just defines the broad types of
> data to be returned (string, list, dict, etc) but not the internal
> components of complex types.

Took a new approach and created a new output attribute, 
serial_number_hex, that is displayed separately.

UI portion added as well.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-rcrit-924-2-serial.patch
Type: text/x-diff
Size: 8969 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120306/193be30f/attachment.bin>


More information about the Freeipa-devel mailing list