Magento2: Plugin does not appear to respect different scopes?

[MagicLegend]

Magento 2.4.1 Enterprise (the request below is lying) ShipperHQ 20.40.1 from Composer

Hi,

For our client we have two Magento website scopes in which the ShipperHQ module should work. However, I cannot get the plugin to behave. Upon only giving API keys to the correct Magento scopes, the refresh page will complain that ShipperHQ is not responding, please check your settings to ensure they are correct. However, as soon as I added the same credentials to the default Magento scope; it all just worked. Given that the docs state the following; I assume that only using specific Magento scopes (and not the default Magento scope) is a valid use case:

If you have multiple websites that will run different ShipperHQ configurations, you’ll need to create each website in ShipperHQ and collect the API Key and Authentication code. Then, within the Shipping Methods > ShipperHQ website settings, uncheck the “default” setting and override the API Key and Authentication code for each of your websites.

In the logging I see the following request being made repeatedly:

[2021-03-02 07:37:30] ShipperHQ Logger.DEBUG: Shipperhq_Shipper-- Allowed methods response-- array (
  'json_request' => '{
    "credentials": {
        "password": null,
        "apiKey": ""
    },
    "siteDetails": {
        "ecommerceCart": "Magento 2 Community",
        "ecommerceVersion": "2.4.1",
        "websiteUrl": "http:\\/\\/localhost:38835\\/admin\\/",
        "environmentScope": "INTEGRATION",
        "appVersion": "20.40.1",
        "ipAddress": ""
    }
}',
  'url' => 'https://api.shipperhq.com/v1//allowed_methods',
  'response' => '{
  "errors" : [ {
    "errorCode" : 3,
    "internalErrorMessage" : "Invalid Credentials. The credentials you supplied are invalid.",
    "externalErrorMessage" : null,
    "priority" : 999
  } ],
  "responseSummary" : {
    "date" : 1614670650061,
    "version" : "1.17.269",
    "transactionId" : "SHQ_20210302_0737_ip_10_0_110_184_8835126",
    "status" : 0
  }
}',
) [] []

For some reason, it tries to make requests with an empty API key, I presume it's trying to use the default credentials (I put the ShipperHQ scope on Integration to test this theory, and as you can see above, it did use said ShipperHQ scope) - that don't exist, and where the plugin is disabled. Note that there are also requests that do use an API key, and get a valid response. However, the plugin appears to just ignore those, since it got an error back on another request.

How am I supposed to handle this? I can't just add a dummy key to the default Magento scope, since the client needs both websites the plan allows for for actual websites (two locales).

Thank you.

[ibraheemnabeelfauzi]

Hey, @MagicLegend here is what I recommend trying here.

1- Login to the Magento dashboard go to every site below the default scope and make sure "Use default" is ticked on every one of them. 2- Go back to the default scope (dump in and the API key/Auth code that one of these two websites will be using > Synchronize > save). 3- Once that is done in place now go back and navigate to the 2nd website that will need to feed rates/configurations from another scope/website and then dump in the credentials in there and save. The scope can be different as well on this one as you'll get the option to pick the desired scope - it must **match** what's been copied from SHQ so if the key/auth are from INTEGRATIONS, then the scope in Magento MUST be INTEGRATION on that website only.

What you'll end up with is one website feeding from the default scope in Magento while the other feeding from another set of API key/Auth code and a different scope.

This should get you going but if you run into issues pass store URL/Magento login email address and company name on support@shipperhq.com.

Thank you.

[MagicLegend]

Hi @ibraheemnabeelfauzi

Thank you for responding! I've actually come up with a workaround for my issue. I've added the same keys for the US store to the default scope, and the US store scope. This appears to fix the issue as well. However, the plugin shouldn't require keys in the default scope when it's explicitly disabled there. I think this could be a bug in the plugin itself.

Do you think there could be unexpected consequences from this double configuration?

Thank you.