_x getting removed from package ID

Hi Peter,

I believe this happens in APEX sdk when preparing outbound payload (source code here, remove_x function). This is because some keywords are reserved in APEX that's why they are carrying "_x" suffix as property names. Without further testing, I think it worth trying like removing package id by setting pkg.id = null; (The passed in parameter packageId is part of the API url, so I doubt it's caused by that). I will put more time to investigate when I got chance today.

Duo

Hi Peter,

Just did a quick test and adding this line seems resolved the issue:

            OneSpanSDK sdk = new OneSpanSDK();
            OneSpanAPIObjects.Package_x pkg = sdk.getPackage('UkiWmQ5bwL3ROlb_XQr6adSgAiE=');
            pkg.trashed = true;
            pkg.id = null;
            sdk.updatePackage(pkg, 'UkiWmQ5bwL3ROlb_XQr6adSgAiE=');

Inspired from this issue, I think it's worth to remove package id from retrieved package for every occurrence before the updatePackage call.

Duo

Thanks, Duo! I'll give it a try.  I think this will also solve an issue we were seeing the signer URL was malformed when _x was present.  

One more question on this, for a very low percentage of users, we have seen an issue where the signer token is malformed in the URL. We've noticed the character length was different between a valid and invalid url.  Is it possible that if a login token includes _x it is getting dropped by the SDK?

For example, this is the login token for a url that failed:
R3h3ZnkvNVRyWm9zVzA4ZS94c2ovYnRDQ3kwNEducUlqdmliS0MrQW9GRFkvTFZETHduUFFkYnhtaVpiYnorMlhxdDlrdlp2ZW9ISmxoMUVpNEh6RUd1ZGMrWHdHQ0h2Y0hGdk90eCs4Mk9WdmdQcFhzYzVBOGREM2hHUW5NdXBUazlWWjJ0RGFUbFNNazgyYjNKcGNEW_XnZkRnBFUzBaYVkwVmFaR0ZLVTNOaVNtb3pZMEV5TWxKQmFFdHdaVmhXYW5CM1IwRTJhbFJNVUVSbGIyeGhZVzh1TXMwWGpCTjFLMlRKTHNjekJESmpQRXRLM2taUnFSL3pUZlA3WlluRw%3D%3D

This is a login token that was successful: cERrOHV5WnE1bCsyVUkxd0g3eVpuM2N6S2lYWG43Q3l0REtOUFZHY0I4bFdsbXJaN24wN3dPbzllL29QUnNpSG80aTBHSmpIRDBNQzVka3U5Y1BoQzdxN3BoTDZ6T3FMZXE1cXBrdWJRK1YrdzFXeW9hVXhSUmg1RjNOQzZvTTVha1JIVW5kSU1VMHlUMk5GY1VWYVJsaERTSFZCV25waE5VWnBhRlJ1VEV0VWRtSnNZbTFuV2pCTGNIQmhOSGRKZGtwTldHVlFZWGRKUzJSMVIzSkZReXNXZkZIV2VreWxkMU0rcEVJNGRNR1VQeFZ4aGMyaXlXWkFNRWwxdHhVTw%3D%3D

The character count difference is 2.

Any thoughts on this one? Am I off base here?

Hi Peter,

Sorry that I missed your reply in this thread. The theory of containing reserved words like "_x" makes great sense to me!

But I am wondering how you are generating the signing URL. I doubt the ootb APEX sdk has this function, were you creating your own function like the shared code I created in this guide?
https://community.onespan.com/documentation/onespan-sign/guides/feature-guides/developer/creating-signing-session#tab-header-3

Or did you modified based on an existing SDK function?

In your failed login taken, I noticed that there's a "NEW_X" in the second line, this could because the inbound JSON contains "NEW" and it's replaced to "NEW_X" by the function OneSpanJSONHelper.cls > prepareInboundJSON:

    public static String prepareInboundJSON(String jsonString)
    {
        if(String.isNotEmpty(jsonString))
        {
            Map<String, String> inboundReplacementMap = getInboundReplacementMap();
            for(String key : inboundReplacementMap.keySet())
            {
                if(jsonString.contains(key))
                {
                    jsonString = jsonString.replace(key, inboundReplacementMap.get(key));
                }
            }
        }
        jsonString = removeNullProperties(jsonString);
        return jsonString;
    }

    private static Map<String, String> getInboundReplacementMap()
    {
        Map<String, String> inboundReplacementMap = new Map<String, String>();
        inboundReplacementMap.put('"enum"', '"enum_x"');
        inboundReplacementMap.put('"from"', '"from_x"');
        inboundReplacementMap.put('"group"', '"group_x"');
        inboundReplacementMap.put('NEW', 'NEW_X');
        inboundReplacementMap.put('PACKAGE', 'PACKAGE_X');
        inboundReplacementMap.put('PACKAGE_X_X', 'PACKAGE_X');

        return inboundReplacementMap;
    }

Duo

Hi Peter,

For the signing URL issue, I would suggest to add a new method "doGetWithoutPrepareInboundJSON" in OneSpanRESTAPIHelper.cls and modify the getSigningUrl method to receive the response without replacing the reserved words:

    private HttpResponse doGetWithoutPrepareInboundJSON(String resourceUrl)
    {
        // Build Request
        HttpRequest request = new HttpRequest();
        request.setEndpoint(connectionSettings.Endpoint__c + resourceUrl);
        request.setMethod('GET');
        request.setHeader('Authorization', 'Basic ' + connectionSettings.API_Key__c);
        request.setHeader('Content-type', 'application/json');

        // Send Request
        HttpResponse response = (new Http()).send(request);

        if(response != null && (response.getHeader('Content-Type')).contains('json'))
        {
            response.setBody(response.getBody());
        }

        return response;
    }

    public OneSpanAPIObjects.SigningUrl getSigningUrl(String packageId, String signerId)
    {
        // Send Request
        String resourceUrl = '/packages/' + packageId + '/roles/' + signerId + '/signingUrl';
        HttpResponse response = doGetWithoutPrepareInboundJSON(resourceUrl);

        // Check response
        OneSpanAPIObjects.SigningUrl signingUrl;
        if(response.getStatusCode() == 200)
        {
            try
            {
                signingUrl = (OneSpanAPIObjects.SigningUrl)JSON.deserialize(response.getBody(), OneSpanAPIObjects.SigningUrl.class);
            }
            catch(Exception e)
            {
                throw new OneSpanRestAPIHelperException('Error obtaining OneSpan signing Url: ' + e.getMessage());
            }
        }
        else
        {
            throw new OneSpanRestAPIHelperException('Error obtaining OneSpan signing Url: ' + response.getStatusCode() + ' - ' + response.getStatus() + ' - ' +  response.getBody());
        }
        
        return signingUrl;
    }

Duo

@Duo so what doesn't make sense to us is that y'all's Apex SDK is stripping "_x" and "_X" from anything that gets returned in a Json string. See attached screenshot.

We understand that "_x" is used with reserved words in Apex, but how does that create any issues with returned Json? Doesn't seem like it would create issues and in other projects where we have not used the Apex SDK we have not had any of these problems.

The bigger issue created by this is that OneSpan often puts an "_x" into the package Id, which makes the package unusable with the Apex SDK right? We need that Id returned in full so that we can actually do stuff with the package.

This design and build doesn't make sense to us and we need some help getting around that limitation. Thanks!

Hi Chris,

Yes, you're correct that the Apex SDK only strips "_x" and "_X" in outbound payloads, not in inbound responses. However, there are two scenarios where this can still cause issues:

(1) For inbound scenario, a good example is the get signing URL call. In very rare cases, the returned signing URL might include reserved keywords like "NEW", which triggers the inbound replacement logic:
private static Map<String, String> getInboundReplacementMap()
{
   Map<String, String> inboundReplacementMap = new Map<String, String>();
   inboundReplacementMap.put('"enum"', '"enum_x"');
   inboundReplacementMap.put('"from"', '"from_x"');
   inboundReplacementMap.put('"group"', '"group_x"');
   inboundReplacementMap.put('NEW', 'NEW_X');
   inboundReplacementMap.put('PACKAGE', 'PACKAGE_X');
   inboundReplacementMap.put('PACKAGE_X_X', 'PACKAGE_X');

   return inboundReplacementMap;
}

(2) For the randomly generated fields like package ID, they could sometimes include "_x" or "_X" by chance. If they do, the inbound replacement logic might accidentally strip them in subsequent PUT or POST calls.

Duo

@Duo ok thanks for response!

We are going to implement your suggestions and see if that fixes the problems.

That being said, we are seeing a significant % of package Ids containing "_x" or "_X", which just seems very problematic from the OneSpan side since y'all are passing reserved character strings back to SF.

Do you think it would make sense to just do a product enhancement to avoid those reserved strings?