Is it possible to use a Secured API Key in combination with another filter that is not defined inside the key?
For example, the secure key would define which items the user can access, but each search would be performed with an additional filter to limit the results by date (date > now).
Generating a new key (including the date) before each search is not practical, as it should be done on the server.
Yes it's possible. You can apply any additional filters as in a regular query, these ones will always be applied after those contained in the secured api key itself.
Related
Can I add an unique custom field inside a work item.
So when a new work item is added, a validation error occurs if a previously added work item already contain a that value.
I've tried inside the "Rule" section of work item customization, but without success
There is no built-in rule to enforce uniqueness. The only field that is guaranteed to be unique is the work item ID.
It is possible to create a custom control that uses the REST API to query whether the contents of a field are unique and have it enforce that uniqueness. But that has a few caveats. The rule will only be enforced in the UI, other experiences (like bulk changes, excel etc) won't triggr this validation. Direct manipulation through he REST API won't either. And I would expect concurrency problems when you venture in this direction.
I am building a simple API service using Ruby on Rails. In production, I would like to integrate Redis/Memcached in order to cache some frequently-used endpoints with key-based caching. For example, I have a Car table with name and color fields.
My question is, what is the best way to define a cache key for a particular endpoint (eg. /cars) when the resource has variety of params that could come in different order? eg. /cars?name=honda&color=white, /cars?color=white&name=honda.
If I use request url as cache key I will have 2 different cache records but technically speaking, if both name and color have the same values, there should only be one cache record in Redis database.
arrange the parameters in alphabetical order and use that as the basis for a cache key.
/cars?name=honda&color=white
/cars?color=white&name=honda
in both cases the cache key would be based on the concatenated alphabetically listed parameters
colorname
So both the above reordered urls would result in the same cache key.
I would like to offer full-text search to my users through their data - and make sure that they can only access the data they own. Are there any patterns allowing to do that on Algolia ? None of the solutions I've considered seem a good fit, so i was wondering if I had overlooked some other options.
We could host each user's data in a separate Algolia app, so that each API key would give access to only the relevant data, but that would quickly become unaffordable, as many would hit the 10000 records limit.
We could host each user's data in a separate index and use team index restrictions, but there does not seem to be an API to manage those, and that would anyway require an Algolia account for each customer, which seems like a misuse of the service (we could e.g. generate email addresses at our domain name).
Finally we could filter queries with some userId to retrieve only the relevant data, but that wouldn't be secure, as someone could use the apikey to query algolia without the filter.
We could proxy algolia calls to inject the filter and the api key - but the perf penalty would probably be high.
Any other suggestions ? Thanks!
I got a great answer from rayrutjes at Algolia, so I'm pasting it here in case :
The best approach for your use case is to use what we call generated API keys. Here is the documentation for the JavaScript client: https://www.algolia.com/doc/api-client/javascript/api-keys/#generate-key
The usage is fairly simple, you generate an API key on the fly based on your search API key + some additional query params.
The resulting API key can be used like a standard search API key, with the difference that it can be scoped on a given set of parameters.
Note that the generation of such a scoped API key does not require an actual call to the API.
Also be sure to generate those scoped API keys in the backend as in that case you don't want to expose the search API key you use for their generation.
with Algolia is it possible to restrict the attributes to retrieve when building a Secured API Key?
By defualt, when searching, attributesToRetrieve parameter may be used, however I am not sure if it's possible to get used during the generation of a Secured API key.
The reason of this is because we want to restrict certain attributes of a document to specific users.
Unfortunately, it's not possible to restrict the attributes to retrieve using the attributesToRetrieve query parameter while generating the Secured API key -> the user will still be able to override it at query time.
The only thing you can do is configure the unretrievableAttributes setting in your index settings. This setting forces some attributes to be non-retrievable whatever the attributeTo{Retrieve,Highlight,Snippet} query parameter you set.
Currently, I have this resource:
GET /orders/{orderNumber}/{provisionId}/{taxYear}/docs
This returns the given order's documents. An Order is identified by three numbers: orderNumber, provisionId and taxYear. That is the primary key in the database.
I think this is a bad resource design and I want to change it, instead of use different path params for each composite primary key's part.
Is there a standard to model this kind of resources? I don't know how to manage entities that have composite id.
I have thought to do this:
GET /orders/{orderNumber,provisionId,taxYear}/docs
This would be one path param for the order identificator and server would split it to obtain each part.
Another choice I have thought is by query params:
GET /orders/docs?orderNumber=1234&provisionId=1054&taxYear=2015
But I think the last one wouldn't be semantically correct in REST architecture, since in this case query params are required and are not " search filter" params.
Is there any standard to do this? Which is the better choice?
Thanks