_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