Skip to content

Decoded USNat string and MSPA values do not match as of 3.1.3 #81

Description

@gilluminate

even after setting the MSPA related field values, the resulting GPP string is encoded incorrectly, causing those values to decode as 0's

import { CmpApi, UsNat, UsNatField } from "@iabgpp/cmpapi";

...

cmpApi.setFieldValue(UsNat.NAME, UsNatField.MSPA_COVERED_TRANSACTION, 1);
cmpApi.setFieldValue(UsNat.NAME, UsNatField.MSPA_OPT_OUT_OPTION_MODE, 2);
cmpApi.setFieldValue(UsNat.NAME, UsNatField.MSPA_SERVICE_PROVIDER_MODE, 1);

console.log(cmpApi.getGppString());

In my test case, the cmpApi.getGppString() is returning DBABLA~BVAoAAAAAABk.QA.

Plugging DBABLA~BVAoAAAAAABk.QA into https://iabgpp.com/#DBABLA~BVAoAAAAAAGQ.QA results in all 3 of those MSPA fields to be 0!

This seems to be directly related to this change cba7ad2#diff-4200c161641fdfd9f4669e2edd164388654dcb582d43d7980c26be68f3f9c8e8R96 where extra 0's were added to both the SENSITIVE_DATA_PROCESSING and KNOWN_CHILD_SENSITIVE_DATA_CONSENTS default fields, because reverting that specific change results in the MSPA values to decode correctly. Additionally, with or without reverting that change, the array length returned from https://iabgpp.com/#DBABLA~BVAoAAAAAAGQ.QA in SensitiveDataProcessing is 12 no matter what, and KnownChildSensitiveDataConsents is 2 no matter what. Obviously the encoder is still expecting only those exact number of values.

Those array size changes were probably done for a reason, so I hesitate just reverting that change. I'm continuing to investigate where that change is causing problems and will try to provide a PR soon.

Metadata

Metadata

Assignees

No one assigned

    Labels

    encoder toolreviewedFor library maintainers only. Indicates that this issue was reviewed.

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions