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
# ipa service-show HTTP/rawhide.example.com
Managed by: rawhide.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
Displaying a host or a service in the webUI fails with "IPA error
invalid 'serial_number': Decimal or hexadecimal number is required for
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
probably also save me a hack in the type conversion overhaul. You
for example add a parameter flag like "format_serial_number" to
to the client that it should format the value as a serial number.
Well, we want to do as little client formatting as possible. The
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,
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
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.
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?
Freeipa-devel mailing list