Bug 1476028
| Summary: | Id Cert Serial number should be less than 53 bits wide or be a string in JSON response | ||
|---|---|---|---|
| Product: | [Community] Candlepin | Reporter: | Shayne Riley <sriley> |
| Component: | candlepin | Assignee: | Abhishek Kumar <abhiskum> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2.3 | CC: | abhiskum, csnyder, khowell, nmoumoul, redakkan |
| Target Milestone: | --- | Keywords: | Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | candlepin-3.1.2-1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-11-22 11:05:25 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Al, we wanted your thoughts on this one... Yeah, providing it as a string in the JSON response seems reasonable to me. It may be tricky with Jackson though since I imagine we will still want it to be a long internally but we'll need to tell Jackson to serialize it as a string. We'll also need to look through subscription-manager and see where/how it uses the serial. My instinct is that subscription-manager will be agnostic toward the data type. Nice catch, Shayne. Thank you for your interest in Candlepin. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the project, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to open a new bug with more up to date details. Thank you. |
Description of problem: The ID certificate serial number is a long (64-bits). It gets serialized into JSON, and returned to the client. The client may deserialize this into a double, which can only have an int up to 53-bits long before precision gets lost. This is a problem because some tools and libraries, most notably any modern browser, node.js, jq, and probably more, will load numerical values not as a long, but as a double, and the serial number is now incorrect. Since it is entirely possible for a javascript client to exist which would handle consumer payloads, the ID certificate serial number should either: - fit in 53-bits - be a string And if we're changing the "serial" value, we should change the "id" value too, since they both are equal, from what I see. How reproducible: Always Steps to Reproduce: 1. Get any consumer from candlepin, which should include the id-cert serial number. 2. Grab the id-cert serial number. Here's an example one: 2549664266108101582 3. Open your browser's developer tools window (ctrl+shift+I) 4. Paste this into the console prompt: JSON.stringify(JSON.parse('{"idCert": {"serial": {"id": 2549664266108101582}}}')); Actual results: You get this output: {"idCert":{"serial":{"id":2549664266108101600}}} Expected results: Well, that's the thing, is this is expected since we're treating the serial as a number, rather than as a string. If it were a string, we wouldn't worry about precision loss.