Bij het ontwikkelen van Hyva-compatibiliteitsmodules met modules van externe ontwikkelaars (Amasty / Yireo / MagePlaza / EheadWorks, enz.) is het vaak nodig om delen van de code die communiceren met de Magento2 REST API te herschrijven.
Zoals we weten, gebruikt Magento 2 de sessiegebaseerde authenticatiemethode. Wat betekent dit?
Het Magento web API framework gebruikt uw ingelogde sessiegegevens om uw identiteit te verifiëren en toegang tot de gevraagde bron te autoriseren.
Klanten hebben toegang tot bronnen die zijn geconfigureerd met anonieme of zelftoegang in het configuratiebestand webapi.xml. Voor meer informatie kunt u de officiële handleiding raadplegen: https://devdocs.magento.com/guides/v2.4/get-started/authentication/gs-authentication-session.html.
Bijvoorbeeld, we hebben het zogenaamde webapi.xml-bestand dat de web-API voor de klantenservice definieert:
Het attribuut force="true" betekent dat de parameter customerId gedwongen wordt overeen te komen met de ID van de momenteel ingelogde gebruiker. gebruiker en zal automatisch worden gebruikt vanuit een klantensessie. Je kunt meer lezen over het afdwingen van aanvraagparameters in het artikel: https://devdocs.magento.com/guides/v2.3/extension-dev-guide/service-contracts/service-to-web-service.html#forced-parameters
We hebben bijvoorbeeld een endpoint /V1/third-party/mine/highlight/category (modules van derden kunnen hun eigen endpoints hebben die klantautorisatie vereisen). We gaan nu een frontend-gedeelte van een module van derden converteren, dat een aanvraag uitvoert naar een endpoint ():
In Hyva-terminologie wordt dit gedeelte als volgt herschreven in het .phtml-bestand:
Ik sla onnodige parameters over die niet relevant zijn. Het is hier belangrijk om te zien hoe we storage.post vervangen in de fetch-methode.
Ik heb geprobeerd deze implementatie uit te voeren en kreeg dit foutbericht:
Wat betekent dit? Ik vond het antwoord hier: https://magento.stackexchange.com/questions/181161/magento-2-session-based-authentication-doesnt-work
Na verder onderzoek bleek dat de fetch-aanroep anders werkt dan jQuery.ajax() en niet de X-Requested-With header standaard.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
De fetch-specificatie verschilt op de volgende belangrijke manieren van jQuery.ajax():
De Promise die door fetch() wordt geretourneerd, wordt niet afgewezen bij een HTTP-foutstatus, zelfs niet als het antwoord een HTTP 404 of 500 is. In plaats daarvan, zodra de server reageert met headers, de De Promise wordt normaal afgehandeld (waarbij de ok-eigenschap van het antwoord op false wordt gezet als het antwoord niet binnen het bereik 200-299 valt), en wordt alleen geweigerd bij een netwerkfout of als iets de voltooiing van het verzoek heeft verhinderd.
fetch() verzendt geen cross-origin cookies, tenzij u de credentialsinit instelt. (Sinds april 2018. De specificatie heeft het standaardbeleid voor inloggegevens gewijzigd naar same-origin. Firefox is gewijzigd sinds 61.0b13.)
Om alles te laten werken, moeten we de X-Requested-With-header toevoegen zoals hier:
En nu werkt het zoals we willen, we hebben de autorisatie succesvol doorlopen!
