JSON API on Mivatest dev store

[ids]

Is there any reason JSON API can't run and be developed on a Mivatest dev store? Is there a misconfiguration in the dev store?

I'm seeing complaints in the response about an invalid date and the endpoint in the response is a cloudflare url, not what I submitted. The content type is also not what is submitted.

<mvt:call action="g.endpoint" method="'RAW'" headers="g.headers" content-type="'application/json'" fields="'g.json_data'">
 <mvt:eval expr="s.callreturnheader1" /><br><br>
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader1 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader2 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader3 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader4 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader5 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader6 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader7 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader8 $ '|'" />
    <mvt:assign name="g.cr" value="g.cr $ s.callreturnheader9 $ '|'" />
    <mvt:assign name="g.response" value="g.response $ s.callvalue" />
</mvt:call>

Order Load Response: <br>
&mvt:global:cr;<br />
<textarea rows="20" cols="200">
&mvt:global:response;
</textarea>
<br>

Works on my own store (not a dev store, no cloudflare). I've verified the access tokens are correct and privileges' are set correctly per the store.

Payload should have nothing to do with the call, but here's the JSON API payload:

{
   "Miva_Request_Timestamp": "1683050694",
   "Store_Code": "STOREIDHERE",
   "Function": "Product_Update",
   "Iterations": [
      {
         "Edit_Product": "PRODCODE1",
         "CustomField_Values": {
            "baskinv": {
               "total_inv": 1
            }
         }
      },
      {
         "Edit_Product": "PRODCODE2",
         "CustomField_Values": {
            "baskinv": {
               "total_inv": 2
            }
         }
      }
   ]
}

If it helps, here's the first line of the response.

Order Load Response:
HTTP/1.1 401 Unauthorized|Date: Tue, 02 May 2023 19:08:22 GMT|Content-Type: text/html; charset=iso-8859-1|Content-Length: 457|Connection: close|www-authenticate: Basic realm="Protected_Dev_Site"|CF-Cache-Status: DYNAMIC|Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?

I'm wondering if it's a firewall rule in Cloudflare?

[Brennan]

The response your getting is a 401 error. So either your request is getting blocked by cloudflare firewall or the endpoint is hidden under a username/password.

This shouldn't be related to the DTS store itself, its something to do with the endpoint.

[lesliekirk]

The response your getting is a 401 error. So either your request is getting blocked by cloudflare firewall or the endpoint is hidden under a username/password.

This shouldn't be related to the DTS store itself, its something to do with the endpoint.

Brennan, Scott said it "works on my own store (not a dev store, no cloudflare)." Wouldn't that indicate it's not something at the endpoint? What would be different in the configuration of Scott's own store and the DTS store?

[Brennan]

In the response it has: Protected_Dev_Site so this seems to indicate that the site has basic http authentication enabled. Can you remove this to be able to test it, or you can pass a header in your API request with the correct credentials.

[lesliekirk]

In the response it has: Protected_Dev_Site so this seems to indicate that the site has basic http authentication enabled. Can you remove this to be able to test it, or you can pass a header in your API request with the correct credentials.

I happened to encounter 'Protected_Dev_Site" just this morning when a store owner asked me if I could remove the password-protected directory from their dev site. The "title" of the protected area was "Protected_Dev_Site". If this is what you are referring to, I found it in the Plesk admin for the site.

XivPO1.png

[ids]

Leslie, Thanks for asking that question to Brennan. Totally slipped my mind that this newly created dev store copy is password protected. I can check this out myself. Thanks Brennan.

Scott

[ids]

UPDATE: The password protection has been removed for now. Here's the the first and only line of the error response.
I have also confirmed my template code works with the appropriate access token, etc in the client's production store.

Order Load Response:
HTTP/1.1 200 OK|Date: Wed, 03 May 2023 18:51:38 GMT|Content-Type: application/json; charset=utf-8|Content-Length: 82|Connection: close|vary: Accept-Encoding|x-powered-by: PleskLin|CF-Cache-Status: DYNAMIC|Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=uaq484K8p2ZHHQAwqZ1K5JOjczmE92yMLKjqBaFf5D4m2 W4myhtmemnZp2FRos5Ybqr%2FrXxag0Jrz8V1dXVWlmMQE0EE4 f9vMgHL9002jTX2ji1hFBZ%2F0yE18iXxRK%2FevMobHly3KGg UgGWM%2BPwqugzTxlDZMTA%3D"}],"group":"cf-nel","max_age":604800}|

I thought I understood that the mivatest dev stores automatically use some sort of CloudFlare configuration. The production store for this client doesn't use any caching/CDN service. So this is likely a firewall rule of some sort isn't it?

Scott

[ids]

Finally got a resolution for this. So here are the general details the way I understand them -- for posterity sake.

Mivatest dev stores are indeed configured with CloudFlare. There were no firewall rules needed for json.mvc endpoints.

The JSON API Access Token however was being blocked because of IP address range by CloudFlare. This means the IP address restrictions in the Access token screen was incorrect. I was using the current no restrictions setting: 0.0.0.0/0 which is the IPv4 and adequate for most Miva stores. But the CloudFlare config for Mivatest.com is also setup with IPv6. Therefore, for my application of the JSON API access token on this dev store, I needed to add ::/0 for any IPv6 address.

So the take away for dev stores, after all has been said and done: The call to the endpoint needs to handle protected folders with the username/password and use both IPv4 and IPv6 in IP address restrictions fields.

Hope this saves someone else some valuable time.

Scott