Preface:
I planned to write a fresh series of articles under the title – “Sitecore Reboot”. In continuation with my “Sitecore – Yesterday…Today and Tomorrow” post, how, with the lastly released Sitecore XM Cloud, sitecore has gone all SaaS and related to that.
This article was lined up as second one on that series. But unfortunately I am not able to finish working on the first part yet, so instead of waiting anymore, thought of sharing this one first.
Sitecore API Key:
So most of us know that in order access Sitecore GraphQL or Sitecore Layout Service we need an API Key (SSC API Key authentication). We’ll be creating that API Key under /sitecore/system/Settings/Services/API Keys/ based on the template /sitecore/templates/System/Services/API Key.
This API Key template has the following fields,
CORS Origin: Here you can specify the origins other than this application’s own origin, whose request can be allowed to be processed.
Allowed Controllers: Specify the controllers that can be accessed using this API Key. i.e., LayoutServiceController, GraphQLController etc
Impersonation Users: For anonymous users, you can specify the user here usually extranet/anonymous. This will be used to determine the security context of the JSS App to Sitecore content.
Simple and straight forward right?. That’s what I thought too until I saw the last field – Throttle Strategy. This was kind a new to me.(Although I’m aware the logic behind it, I wasn’t aware of this terminology).
In the sitecore documentation related to API Key – Create a Sitecore API key I was not able to find any content related to this…… NICE.
This stirred my curiosity and I checked the templates and started to browse about Throttle Strategy in general.
So what is Throttling in terms of Web API Development?
Throttling is the means by which you can set how your API can serve the incoming requests. By this I mean, one can put some rules for serving the request. One simple such rule is – Number of requests that can served per time unit. When a request even though it’s legitimate by all other means can be stopped from processing using such throttle strategy.
Okay, why would I even need that?
- It offers more security. The Sitecore Layout Service or GraphQL end points are all means to connect with the Sitecore backend. Including throttle strategy includes an extra layer of protection.
- A throttling rule can be applied based on IP Location. Some days ago, I read a case study related to Amazon India where in a particular region, some regional sellers were making more orders and cancelling them before delivery (for obvious reasons) and Amazon has blacklisted that region temporarily. Throttle Strategy can be set to limit the number of requests per time unit from a region. (It may sound paranoid or doesn’t make any sense for some. I’m just saying such measures if needed can be done by throttling strategy)
- Finally, it can improve the performance by preventing the excess use. In cases like Auth0 or any other such Cloud based Identity Management, the API requests are monetized. Meaning like for a given time frame this much requests are free and if there are more than allowed count, they will be charged per request.
Let’s get back to Sitecore, Sitecore provides two OOTB option to specify throttling strategy.
Sliding Window Strategy: Specify the number of requests that can be served per time unit. Any request beyond that number will not be processed.
Composite Strategy: You can configure multiple strategy into a single composite strategy and can set them to your API key
And just like any other feature in Sitecore, you can also create your own custom throttle strategy following this link – Create a new request throttling strategy (sitecore.com)
So, you have created the API Keys, have set the throttle strategy is that it?
We have to enable the throttle strategy by setting Sitecore.Services.IsThrottleEnabled key to true in Sitecore.Services.Client.config,
Now, I could have just believed sitecore and moved on to my next activity. But being the weirdo, I am, I wanted to test myself and see the results and for that I wrote a dummy console application.
When the throttle strategy is set to 1 Request per Second Sliding Window Throttle Strategy.
Only the first request is served and the remaining requests are not processed and are give TooManyRequests StatusCode in the response.
When the throttle strategy is set to 10 requests per 30 second
Here you can see the first 10 requests sent at one second interval each getting served while the next set of requests are not processed and after 30 seconds the next request is processed. By the time this happens for the next 30 seconds already 10 requests are processed so again requests will be responded with TooManyRequests Status.
Using the Composite Strategy, you can combine any such strategies.
The same can be tested via browser, but complicated scenarios that I intended to test can be better done with code. Hence that dummy console application. However, when tested in browser for a simple throttle strategy if it fails the condition the response you get is below.
Sitecore Blog 