I wanted to share an idea and see if anyone else thinks it would be useful. Currently, when working with the File Name Denylist settings, we have to add the entire file name to block it. But wouldn’t it be super convenient if we could use wildcards instead?
For example, imagine being able to add something like *screenshot* to the denylist, and it would automatically block all files containing the word “screenshot” in their names. This would cover files like:
screenshot-01-02-2022.png
screenshot-02-02-2022.jpg
user-screenshot-final.png
I’ve come across multiple scenarios where this feature would save a lot of time and make the denylist settings much more flexible. Instead of listing every single variation of a file name, a single wildcard rule could handle them all.
Has anyone else faced this limitation? Would love to hear if there are workarounds or if this is something that could be considered for future updates.
The File Name Denylist feature was designed to monitor/block file extensions that are not supported by default under the File Type list. The agent reads file names from the right to the left, so you could add an unknown extension like *.abc, which would monitor/block all files that have the .abc extension.
Nevertheless, I think you have a valid point here. It would make sense to enhance the initial feature to have the ability to use wildcards to make it easier to detect file names.
I encourage you to open a support ticket using the Support Portal and we can add the request to the Product Board for consideration.
Thanks!
Thank you for your answer on this topic.
The option to use File Type Denylist for blocking unknown extension is really useful, thank you for sharing it with us.
But, as you already mentioned, it really would make sense to add the possibility to use wildcards for this feature. I believe it could help with different use cases.
We already have the feature request opened for this option.
Hope to see this in the future product release.
The current denylists feature (allowing for File Name or File Location alternatives) includes support for implicit wildcards. I recommend referring to the user manual for comprehensive guidance and to see how it applies to your use case: Denylists and Allowlists Documentation. It’s a good idea to compare your specific needs with the information provided in the UM.
[Denylists and Allowlists Documentation]
But it seems wildcards are not specified at all. Does that mean that " * " is applied by default in the beginning of the entry?
Like mentioned in the docuemntation example “.epp” effectivelt translates into “*.epp”
My idea is either not to force the wildcard in the beginning and ad wildcard as an optional character. That would give an option to add it at the end as well.
Or at least give an option of a widcard at the end of the file.
So would be able to cove example like: screenshot-01-02-2022.jpg screenshot-02-02-2022.jpg
Idea I just had today, discussing this thread is also to add something like ’ ? ’ placeholder
Example.
Some time ago we lost a deal becasue we could not block secific files, which had typical filename structure, but were generated to a each employee individually.
With ‘?’ paceholder we could catch them with a strict mask (would reduce false positives).
I think this is worth exploring as a potential feature enhancement by our Product Management team. If you’ve already submitted a feature request, would you mind updating it with the “?” placeholder idea? The more data we have, the better.
