Sometimes, you don’t want your users to search your entire index, but only a subset that concerns them.
Content might be restricted to a specific user as private data, a set of users, a group, or even everybody. Handling access within an index allows to have a fine-grained control over who can search and view what content.
This doesn’t mean you need one index per user. By generating a Secured API key for the current user, you can restrict the records they can retrieve.
Adding an attribute for filtering in your dataset#Found an issue?
Algolia is schemaless and doesn’t have any concept of relationships between objects, so you need to put all the relevant information in each record.
Take a dataset for corporate documents as an example. The index contains the entire list of documents for the company, but has dedicated access control to restrict who can view content.
Consider different users in this company: Angela, Mike, and Ruth. Angela is an executive, Mike the accountant, and Ruth is an engineer.
[{"title":"Financial record Q3 and pipeline forecast","visible_by":["Angela","group/Finance","group/Shareholders"],"objectID":"myID1","content":"..."},{"title":"Compliance audit check-list","visible_by":["group/Finance"],"objectID":"myID2","content":"..."},{"title":"Strategic partnership with BigCompany","visible_by":["Angela"],"objectID":"myID3","content":"..."},{"title":"New company-wide healthcare coverage benefits","visible_by":["group/Everybody"],"objectID":"myID4","content":"..."},{"title":"Ruth's personal TODO list","visible_by":["Ruth"],"objectID":"myID5","content":"..."}]
Each record has a visible_by attribute, which has a list of users, or groups. Only listed users and groups can see the specific record, with the group Everybody visible by anyone. When searching through it, only allowed people should be able to find those records.
In this case, you only want to filter on this attribute, and not use it for facet counts. That means you should add the filterOnly modifier. This improves performance because the engine doesn’t have to compute the count for each value.
If you need faceting on this attribute, you can remove the filterOnly modifier.
With front-end search, malicious users can tweak the request to impersonate another user and see content they shouldn’t have access to.
To prevent this, you can generate a Secured API key, a special key that you can generate on the fly, and within which you can embed a set of filters. End users can’t alter those filters.
$currentUserID='Angela';$currentGroupId='Board';$securedApiKey=\Algolia\AlgoliaSearch\SearchClient::generateSecuredApiKey('YourSearchOnlyAPIKey',// A search key that you keep private['filters'=>'visible_by:'.$currentUserID.' OR visible_by:group/'.$currentGroupId.' OR visible_by:group/Everybody']);
1
2
3
4
5
6
7
current_user_id='Angela'current_group_id='Board'secured_api_key=Algolia::Search::Client.generate_secured_api_key('YourSearchOnlyAPIKey',# A search key that you keep private{filters: 'visible_by:'+current_user_id+' OR visible_by:group/'+current_group_id+' OR visible_by:group/Everybody'})
1
2
3
4
5
6
7
8
9
10
11
// Only in Node.jsconstcurrentUserID='Angela';constcurrentGroupID='Board';constpublicKey=client.generateSecuredApiKey('YourSearchOnlyAPIKey',// A search key that you keep private{filters:`visible_by:${currentUserID} OR visible_by:group/${currentGroupID} OR visible_by:group/Everybody`});
1
2
3
4
5
6
7
8
9
10
fromalgoliasearch.search_clientimportSearchClientcurrent_user_id='Angela'current_group_id='Board'public_key=SearchClient.generate_secured_api_key('YourSearchOnlyAPIKey',{# A search key that you keep private
'filters':'visible_by:'+current_user_id+' OR visible_by:group/'+current_group_id+' OR visible_by:group/Everybody'})
1
2
3
4
5
6
7
8
9
10
intcurrentUserId="Angela";intcurrentGroupId="Board";SecuredApiKeyRestrictionrestriction=newSecuredApiKeyRestriction{Query=newQuery{Filters=$"visible_by:{currentUserId} OR visible_by:group/{currentGroupId} OR visible_by:group/Everybody"},};// A search key that you keep privateclient.GenerateSecuredApiKeys("YourSearchOnlyAPIKey",restriction);
1
2
3
4
5
6
7
8
9
10
11
intcurrentUserID="Angela";intcurrentGroupID="Board";SecuredApiKeyRestrictionrestriction=newSecuredApiKeyRestriction().setQuery(newQuery().setFilters(String.format("visible_by:%s OR visible_by:group/%s OR visible_by:group/Everybody",currentUserID,currentGroupID)));StringpublicKey=client.generateSecuredAPIKey("YourSearchOnlyAPIKey",// A search key that you keep privaterestriction);
1
2
3
4
5
6
7
8
currentUserID:="Angela"currentGroupID:="Board"filter:=fmt.Sprintf("visible_by:%s OR visible_by:group/%s OR visible_by:group/Everybody",currentUserID,currentGroupID)key,err:=search.GenerateSecuredAPIKey("YourYourSearchOnlyAPIKey",// A search key that you keep privateopt.Filters(filter),)
1
2
3
4
5
6
7
valcurrentUserID:String="Angela"valcurrentGroupID:String="Board"valpublicKey=client.generateSecuredApiKey("YourSearchOnlyAPIKey",// A search key that you keep privateQuery(filters=Some("visible_by:%s OR visible_by:group/%s OR visible_by:group/Everybody".format(currentUserID,currentGroupID))))
1
2
3
4
5
6
valcurrentUserId="Angela"valcurrentGroupId="Board"valrestriction=SecuredAPIKeyRestriction(Query(filters="visible_by:$currentUserId OR visible_by:group/$currentGroupId OR visible_by:group/Everybody"))// A search key that you keep privateClientSearch.generateAPIKey(APIKey("YourSearchOnlyAPIKey"),restriction)
Note that this needs to happen on the back end. For example, when a user logs in to your application, you could generate the key from your back end and return it for the current session.
To invalidate Secured API keys, you need to invalidate the search API key you used to generate it.
When using a Secured API key with an embedded filter, users can only retrieve content they’re allowed to access to. Since the API returns the visible_by attribute for each record, they can find out what other users have the same access for this record if they inspect the response.
To mitigate this privacy concern, you can leverage the unretrievableAttributes parameter. It allows you to ensure that the visible_by parameter is never part of the Algolia response, even though you use it for filtering on the engine side.
You can now search on the front end using the API key generated from your back end. This API key has an embedded filter on the visible_by attribute, so you have a guarantee that the current user only sees results that they’re allowed to access.