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.
Related
I'm writing a toy finch project and trying to allow requests to specify arbitrary query parameters to set some value. I am able to retrieve the value for a known parameter name (i.e. param[String]("foo")) but how can I get a Map[String,String] of all the query parameters?
i.e. hit /myendpoint?foo=bar&baz=baq and within the response handler be able to access the value Map("foo"->"bar", "baz"->"baq")
I looked in the docs and there seems to be some way to access all the headers but no equivalent functionality is given for accessing params.
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.
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.
I am trying to create and modify users using SCIM/REST API's available OOTB in 11gR2PS3.
I am able to create/modify users for all the OOTB attributes specfied in the document
As per the documentation, these API's are supported for custom UDFs as well.
Does anyone know what the schema attributes name and format that needs to be passed in the content body for custom UDF's?
As per the documentation
Note: You can use user defined fields (UDFs) in SCIM requests. After
UDFs are created in Oracle Identity Manager, they automatically appear
in SCIM resources as regular attributes. There is no difference in the
requests and responses with regular attributes.
when we crate the user even after specifying the UDF value its not going in OIM DB and it also doesn't throw any exception.
call /Schemasoperation using get method
using your OIM URL :http://<host>:<port>/idaas/im/scim/v1/Schemas
Use the returned schema while using create, update operation on the UDF.
e.g. schema returned is urn:ietf:params:scim:schemas:extension:oracle:2.0:OIG:User
then qualify UDF with the returned schema while calling Create/Update operation.
"urn:ietf:params:scim:schemas:extension:oracle:2.0:OIG:User":{
UDFNAME : UDFVALUE
}
also incluede the schema in the schemas[] if its not there already.
I am currently planning a web API based on the principles of REST. I am using a session token to correct identify what user is making a request (after authentication of course), then determining if that user has access to the given resource.
Assuming the user making the request has a userID of 7, and I am wanting to retrieve a list of only the presentations that he can access, would best/proper practice be to:
1. Include my userID in the route, such as:
localhost:55555/api/users/7/presentations
or
2. Not include userID, such as:
localhost:55555/api/presentations
Each presentation can be accessed by any number of other users. For this reason I am leaning towards option 2 but would like to know what others think before I finalize the structure.
A very common pattern for REST APIs is to have both:
a list resource with optional parameters like /presentation/?by=Alice&since=2013-1-1,
object resources like /presentation/0AFF56E7.
For presentations, I wouldn't use a composite ID containing the user ID, since it doesn't seem really needed and it would prevent future features like changing the "owner" of the presentation (without changing its ID).