|
71 | 71 | cache.GetOrCreateAsync($"user_prefs_{userId}", ...); |
72 | 72 | ``` |
73 | 73 |
|
74 | | -**It is the caller's responsibility** to ensure that this key scheme is valid and cannot cause data to become confused, either between separate uses of `HybridCache`, or based on |
75 | | -different inputs used in the cache key. In particular, it is not recommended to use external user input (in particular, but not limited to, raw `string` values from a UI) as part |
76 | | -of cache keys, as this could allow malicious access attempts, or could be used in a service-denial attack by saturating your cache with data with meaningless keys generated from |
77 | | -random strings. In the above (valid) example, the *order* data and *user preference* data are clearly distinct, where `orderid` and `userId` are our internally generated |
78 | | -identifiers, and `region` might be an enum or string from a *predefined list* of known regions. There is no significance placed on tokens such as `/` or `_`; the composed value is |
79 | | -treated as an opaque identifying string - the examples above just illustrate some common approaches. This guidance applies equally to any `string`-based cache API, including |
80 | | -`HybridCache`, `IDistributedCache`, `IMemoryCache`, etc. |
| 74 | +It's the caller's responsibility to ensure that a key scheme is valid and can't cause data to become confused. |
| 75 | + |
| 76 | + We recommend that you not use external user input in the cache key. For example, don't use raw `string` values from a UI as part of a cache key. Such keys could allow malicious access attempts, or could be used in a denial-of-service attack by saturating your cache with data having meaningless keys generated from random strings. In the preceding valid examples, the *order* data and *user preference* data are clearly distinct: |
| 77 | + |
| 78 | +* `orderid` and `userId` are internally generated identifiers. |
| 79 | +* `region` might be an enum or string from a predefined list of known regions. |
| 80 | + |
| 81 | +There is no significance placed on tokens such as `/` or `_`. The entire key value is treated as an opaque identifying string. You could omit the `/` and `_` with no change to the way the cache functions. |
| 82 | + |
| 83 | +This guidance applies equally to any `string`-based cache API, such as `HybridCache`, `IDistributedCache`, and `IMemoryCache`. |
81 | 84 |
|
82 | 85 | The inline interpolated string syntax (`$"..."` above, directly inside the `GetOrCreateAsync` call) is recommended when using `HybridCache`, as this allows for planned future |
83 | 86 | improvements that bypass the need to allocate a `string` for the key in many scenarios. |
|
0 commit comments