AEM CIF + Magento on Publish | Community
Skip to main content
E
evancooperman-rp
Level 3
May 5, 2021

AEM CIF + Magento on Publish

  • May 5, 2021
  • 3 replies
  • 8898 views

Hi everyone,

I'm struggling a bit to get my publish instance working properly with AEM + CIF (1.10.0) + Venia + Magento.  Everything works properly in author - I can view products, add to cart, and complete checkout.  My commerce config path is set as /api/graphql.

The problem is that in publish, I'm getting a 403 error when it attempts to hit the graphql endpoint:

http://localhost:4503/api/graphql

I have set up the COMMERCE_ENDPOINT environment variable and this is working as expected in author.

I checked the CSRF configuration and by default it only has the /graphql endpoint listed as ignoring CSRF, so I'm assuming that the publish endpoint cannot just be /api/graphql.  I tried adding /api/graphql to the CSRF config just for fun, but that didn't fix it. 

So my question is, in order for publish to work, do I have to set up a proxy and update my config in author (and then publish it) using that URL instead?  I actually tried changing the URL to hit Magento directly, but of course I get a CORS error, so there obviously needs to be a proxy somewhere...I just thought AEM could handle it internally for publish like it does for author.  Does anyone know if I absolutely need to set up a proxy for publish?  Even if I do use a proxy, I'm assuming I would want to use the dispatcher as my proxy so that I don't run into the CORS issue there too, and to avoid a second proxy, right?

I've tried scouring the docs but they all speak primarily to author, with almost nothing at all for how the publish setup differs.  The only thing I see is the following, which seems to indicate that AEM publish should function as it's own proxy the same way author does:

 

Example Mac OSX:

export COMMERCE_ENDPOINT=https://demo.magentosite.cloud/graphql
Example Windows:
set COMMERCE_ENDPOINT=https://demo.magentosite.cloud/graphql
This variable is used by AEM to connect to your commerce system. Also, the CIF add-on includes a local reverse proxy make the Commerce GraphQL endpoint available locally. This is used by the CIF authoring tools (product console and pickers) and for the CIF client-side components doing direct GraphQL calls.
 

Thanks in advance!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

3 replies

moek18753296
moek18753296
Level 2
May 10, 2021

Are you logging in on the publisher first?  If not, I would check the Sling Authentication Service in the OSGi console is set to allow Anonymous access. https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aem-sites-locked-for-anonymous-users/td-p/260595

    E
    evancooperman-rpAuthor
    Level 3
    May 12, 2021
    Great thought, and for a minute I thought you were on to something! Unfortunately my Sling Authentication Service is already allowing anonymous access to the repo. I also tested again after logging in as admin, but getting the same issue still anyway.
      shelly-goel
      Adobe Employee
      shelly-goelAdobe Employee
      Adobe Employee
      May 12, 2021

      @evancooperman-rp  I hope you've activated your /conf/venia cloud configurations

        E
        evancooperman-rpAuthor
        Level 3
        May 12, 2021
        I did activate them, the URL it's attempting to hit in publish is the same as in author (but port 4503), but I'm getting the 403 error.
          shelly-goel
          Adobe Employee
          shelly-goelAdobe Employee
          Adobe Employee
          June 6, 2021

          @evancooperman-rp  Yes the graphql endpoint should be /api/graphql in publish as well. Where do you get 403?

          Is your issue resolved?

            A
            Aryan12345
            Level 3
            February 23, 2022

            Same issue here as well (in 2022 :))

             

            Did you find any solution?

             

            This is the summary of my issue

             

            The /api/graphql is throwing 403 errors which means no frontend commerce operation is happening on the storefront.
             
            I tried adding the /api/graphql to the CSRF filter's exclude list and even removed the POST method from there.
             

             

             
            After this I still 403 on GET request of /api/graphql and the following on POST request.
             

             

             
            I am I missing some setting?
             
            Note: on the sling servlet resolver config, I have added the /api/graphql but there is no change.
             

             

              E
              evancooperman-rpAuthor
              Level 3
              February 24, 2022

              I updated my local dispatcher tools to have an ENVIRONMENT_LOCAL option, and then use that in conjunction with an addition I made to our vhost file like this:

              <IfDefine ENVIRONMENT_LOCAL>
                  ProxyErrorOverride off
                  ProxyPass         /api/graphql http://host.docker.internal:3001
                  ProxyPassReverse  /api/graphql http://host.docker.internal:3001
              </IfDefine>

               so I just use the dispatcher as a proxy.  Since the dispatcher starts in a VM, I believe you also need a local npx proxy in order to forward traffic along to Adobe I/O like this:

              npx local-cors-proxy --proxyUrl https://adobeioruntime.net/api/v1/web/xxxx/graphql-reference/dispatcher --port 3001 --proxyPartial ""

              Hope that helps!

                E
                evancooperman-rpAuthor
                Level 3
                March 9, 2023

                HI ,
                We are running a similar implementation where Commerce system is SAP Hybris by using CIF implementation and IO layer to run graphql queries. Currently am trying to proxy the graphql endpoint for which i followed the above steps in dispatcher vhost file, however i'm getting 503 service unavailable error .

                I have defined COMMERCE to be as true in custom vars and ${COMMERCE_ENDPOINT} in system variable with actual endpoint of the IO runtime. 
                I have also referred other reference and used like below, but no luck.
                <IfDefine COMMERCE>
                SSLProxyEngine on
                #  add ProxyRemote to tunnel reverse-proxy traffic through egress proxy if available
                <IfDefine HTTP_EGRESS_PROXY>
                ProxyRemote ${COMMERCE_ENDPOINT} "http://host.docker.internal:8080"
                </IfDefine>
                <LocationMatch "/api/graphql(/custom)?$">
                # Use an empty back reference from ProxyPassMatch to the LocationMatch regex to prevent the
                # original URL being appended to the proxy request
                ProxyPassMatch ${COMMERCE_ENDPOINT}$2
                ProxyPassReverse ${COMMERCE_ENDPOINT}
                RewriteEngine Off
                </LocationMatch>
                </IfDefine>

                can someone help me here as it is critical to solve the issue and point me with right steps to achieve this .

                 

                Regards,

                Gokul
                @aryan12345 @evancooperman-rp @yonit_david 


                So you get a 503 error when going through the dispatcher, but a 200 when you go directly to Adobe I/O?  I think I'll need a little more info to help.  My use-case from this original post was using a third-party commerce system through Adobe I/O as well, so I know it's possible.  In that case, I remember that Adobe I/O was running over https, so I had to have an additional proxy that just converted traffic from https to http using a self-signed certificate locally, in order to make browser traffic go over SSL, but still hit AEM over http.  I used an npm module called local-ssl-proxy to enable SSL in my local system without having to configure it in the dispatcher, with the command:

                 

                 

                local-ssl-proxy --source 443 --target 80

                 

                 

                (my dispatcher was running on port 80).   This effectively allowed me to make https calls via the browser, and have the browser treat them as SSL calls, but then terminate SSL before sending requests to AEM to avoid issues on that side.  I hope that helps, but might need a bit more info to help further.

                  Terms & ConditionsAccessibility statement

                  Loading footer...