3

Our team is running Sitecore 8.2 Update 4 using a traditional MVC configuration.

We wrote a pipeline that will inject CORS HTTP headers into the response that are configured via an item in Sitecore. However, it would appear that when we actually make the API call, we don't get any headers back. Here's an example of what we are doing:

When we make https://www.mywebsite.com/api/Stations/GetStates, we get these headers:

Cache-Control →no-cache

Content-Length →658

Content-Type →application/json; charset=utf-8

Date →Mon, 11 Jun 2018 17:35:59 GMT

Expires →-1

Pragma →no-cache

Vary →Accept-Encoding

X-ADC →08/09

X-Frame-Options →SAMEORIGIN

X-ID →PZW33CS

X-Powered-By →ASP.NET

As you can see, the Access-Control headers are missing, and those are inserted using a Sitecore pipeline.

We've found out that there is some sort of handler that are defined in the /sitecore/admin/showconfig.aspx that says this:

<handler trigger="~/api/" handler="sitecore_api.ashx"/>

If we change the call to https://www.mywebsite.com/api2/Stations/GetStates (changing the route from api to api2), then we get the headers that we are expecting:

Access-Control-Allow-Headers →Content-Type

Access-Control-Allow-Methods →POST, OPTIONS

Access-Control-Allow-Origin →https://www.myOtherSite.com

Cache-Control →no-cache

Content-Length →637

Content-Type →application/json; charset=utf-8

Date →Mon, 11 Jun 2018 17:43:26 GMT

Expires →-1

Pragma →no-cache

So, it looks like the API handler is messing with things. After doing some research, we can't find that file anywhere in the webroot, so we're not sure how to override/change this behavior. So our questions are:

  1. Is that API route something that should be reserved for Sitecore only calls?
  2. What is the best way to have Sitecore not bypass the pipelines for our API call? Is it truly to use some sort of unique api naming structure such as https://www.mywebsite.com/myapi/Stations/GetStates?
  • What pipeline was your processor that updated the CORS headers being invoked by, <httpRequestBegin> or <mvc.requestBegin>? – vandsh Jun 11 '18 at 20:46
  • 1
    We created a new pipeline in the mvc.requestbegin section. – Keith VanderVeen Jun 11 '18 at 20:51
5
  1. Is that API route something that should be reserved for Sitecore only calls?

    • Yes, /api/ is a reserved space by default. One of the services that falls under this area is the Item Service. And if I recall correctly, hijacking this area (declaring a route in your global.asax or initialize or setting a site definition virtual path to it) results in bad behavior on the shell side of things because some Speak pages use the services in this space.
  2. What is the best way to have Sitecore not bypass the pipelines for our API call? Is it truly to use some sort of unique api naming structure such as https://www.mywebsite.com/myapi/Stations/GetStates?

    • Usually when I am trying to make a backend MVC style call to a controller (JSON, partial HTML, whatever), I end up using /api/Sitecore/ControllerName/ActionName as my route with really no additional setup needed (that I recall).
  • That is a very handy trick. It would appear that when you shortcut by using the /api/ControllerName/ActionName you don't get the Sitecore pipelines, but when you add the Sitecore name after the api, then everything gets called as you expect. That's nice to know. Thanks for the clarification! – Keith VanderVeen Jun 11 '18 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.