Skip to main content

In ConsentTracking controller, we have a server.post(SetConsent) route with couple of middleware steps. When I try to debug using Browser's Developer tools->Network tab, I see that for ConsentTracking-SetConsent call the request method is GET. According to code, it checks if the request is post. But as the request is GET we are getting the params do not match route error. As a result, I am getting tracking consent popup on every page. I am not at all modifying this Controller in my custom cartridge. I don't understand why the http method is changed to GET. 

Is the POST request getting overridden by GET request due to any previous calls?

Can anyone please suggest why is this happening?

 

(Note - This error popped up when I was trying to upgrade SFRA version from 6.0.0 to 6.2.0) 

5 个回答
  1. 7月29日 06:34

    @Giovanni Marchetto

     

    I don’t think a previous call is changing the POST to GET. This usually happens when the frontend code and controller route are not from the same SFRA version.

    Since this started after upgrading from SFRA 6.0.0 to 6.2.0, I’d compare all ConsentTracking-related files, not just the controller.

    Check these:

    1. Search your cartridges for ConsentTracking-SetConsent, ConsentTracking-SetSession, and SetConsent.
    2. See if your custom cartridge is overriding ConsentTracking.js or any consent popup JS/ISML.
    3. Compare those files with the SFRA 6.2.0 version.
    4. Clear cache and redeploy static assets.

    Most likely, the browser is calling the newer GET-based consent endpoint, but your controller/custom override is still expecting POST. So it looks like a version mismatch rather than the method being overridden. 

0/9000