So with the deprecation of this, it will remove the ability to filter charts on ALL fields. This isn’t good at all for my use case and I’m sure others as well.
I understand fully that you’re moving to the SDK, but WHY are you not letting authenticated access to be able to filter on all fields?
Currently, you have to specify which fields can be filtered. I’m very confused by this restriction. My webapp allows users to add custom fields to forms. I can’t specify these fields as I’ll never know.
I went with Atlas because of the schemaless solution it provided. But now it looks like that’s the direction Atlas is going.
If this filter capability gets restricted and removed, then you have caused my business to lose a lot of value and that disappoints me, but it’s your product, so I understand. Please provide any help or solutions or anything.
Thanks
Hi @Protrakit_Support - thanks for raising your concerns. I’ll explain the reason for this restriction, but if it prevents you from using the tool I’d like to learn more about your scenario so we can see if there are other viable solutions.
The requirement to explicitly define filterable fields exists to make embedding more secure. To use a contrived example, imagine if I had a chart showing the average employee salary per department. In aggregate, this information may not be considered sensitive. But if someone added a filter to the chart { employeeName: "Tom Hollander" } the chart would now show information just about me, which would be revealing sensitive information.
Under normal circumstances, the chart filters will only be manipulated by the site’s developer and they will make sure the filters are appropriate. However there is nothing to stop site users from using the developer tools to inject their own filters, so we need to protect against this case by disabling filtering on unexpected fields by default.
Can you elaborate on how you are currently using filtering with your verified signature charts? Is this just a usability issue (e.g. it takes a long time to explicitly allow every field you filter on), or do your documents vary so much that it’s not possible to know in advance which fields might exist?
thanks
Tom
2 Likes
Tom,
Thanks for the quick reply. I completely understand from the security side of it now.
My app lets users create form fields. These form fields can be different types (date, text, number, etc). I’ll never be able to add those as they’ll be ever changing. Plus, these fields are nested within an object in the collection.
If I were able to specify the object without having to select each nested field, then I can definitely make that work. But, you don’t allow that either.
I’m using the verified signature so I can filter on these nested fields.
Got it, thanks. While we do plan on getting rid of the Verified Signature mode eventually, it’s not happening imminently so you can keep using that for the moment. We’ll have a look into what we can do to support your scenario with authenticated embedding before we retire Verified Signature. One idea is to have an opt-in wildcard filter - would that work for you?
Tom
1 Like