[Feature Request] Expose Vision API Asset Identifier Hashing in SDK Utils

[seancrowe]

Problem Description

Currently, the GraFx Studio Designer allows users to override the Point of Interest (POI) and Subject Area for smart cropping via the UI which is then sent to vision a specific Vision API endpoint. An example:

https://cp-ext-123.chili-publish.online/grafx/api/v1/environment/cp-ext-123/external-media/4747819ee6b67d39accfdd508d58bdaca657ba7c6746d583a076e1556526210b/vision

The endpoint uses a unique identifier within the URL path, which appears to be a hash derived from an asset ID. However, the logic for generating this hash is undocumented and not available through the SDK, creating a barrier for developers needing to construct API requests programmatically.

Note

I believe I mean meadId not assetId, from the outside the difference is not that distinct, but based on Nicola's comment and the JSON, I believe this request is about the mediaId.

Proposed Solution

Expose the hashing function used to generate the Vision API asset identifier within the SDK's UtilsController. This will enable developers to programmatically generate the correct identifiers to ensure compatibility with Studio Designer.

Proposed API:

SDK.utils.hashVisionAssetId = (assetId: string) => string;

Functionality:

• Input: assetId (string) - The unique ID of the asset
• Output: string - The hashed identifier required for the Vision API endpoint and aligned with Studio Designer's use.

Rationale:

• The hash appears to be for data storage and retrieval, not security-sensitive. So no reason to keep it secret.
• Exposing this utility aligns with the SDK’s goal of transparency and making sure there is "nothing is magic" with our Studio Designer.

Benefits

• Developer Empowerment: Enables developers to create custom UIs and integrations that directly interact with the Vision API. Which is what I was trying to do.
• Reduced "Magic": Adheres to the SDK’s transparency principle, making mechanisms used in Designer accessible.
• Interoperability: Ensures custom UIs can generate data compatible with the standard used by Studio.
• Simplified Integration: Removes the need for reverse-engineering the hashing algorithm, saving development time and reducing errors.

Acceptance Criteria

• A new function SDK.utils.hashVisionAssetId is implemented in the SDK.
• The function accepts an assetId (string) as input and returns the correct hashed identifier.
• Documentation for SDK.utils.hashVisionAssetId, including its purpose and usage, is provided.

Interim Solution / Workaround

If implementing SDK.utils.hashVisionAssetId is not feasible short-term, please provide the hashing algorithm details (e.g., "SHA-256 of assetId concatenated with secretKey") or an example mapping a known assetId to its corresponding Vision API hash. This information will allow developers to replicate the hashing logic temporarily.

MAIN Ticket

MAIN Ticket: https://chilipublishintranet.atlassian.net/browse/MAIN-1413

[NicolaVerbeeck]

The assumption that only asset id is wrong, we use more information to build this hash

[seancrowe]

Ah, well I thought the hash was purely based on the asset ID - I am curious now what other information you utilize that is static that is also hashed to create a unique identifier

[seancrowe]

I realize the terminology is probably wrong in comparison to the JSON structure - I mean mediaId

[NicolaVerbeeck]

Just checked, we use a hash of connector id (remote id) and media id