Today we're happy to announce a much asked for feature: the support for Regex in string filters. Being able to search data by Regex opens up endless possibilities of finding those needles in the haystack. For example:
Small update - With the Castle event filters you're able to use standard operators like
not equals and for numeric values you've been able to use
greater than and
less than. For convenience, we've now added two new filter options for numeric values:
We've released version 2.2.0 of castle.js, which includes new options for how browser storage is used. There are two new parameters that can be provided in the
We've added a new filter for querying whether an event is considered "authenticated" vs. "anonymous". Authenticated events mean that it was caused by an authenticated user. An example of a non-authenticated is a failed login event, where the credentials match a known user, but where it’s not confirmed that it actually was triggered by the legitimate, authenticated user. Same with password reset requests.
One of the more common asks among our customers is the ability to set up Slack alerts whenever suspicious behaviors are detected. Today we're excited to launch our updated Slack alert feature, which allows you to get notified whenever something is added to a List in Castle. This is great when you want to get notified whenever e.g. a user exhibits a behavior for the first time, such as sharing accounts or doing something repetitive such as sending tons of spam messages
This week, we've introduced a new setting when creating a Policy: the ability to turn off inline responses and let the policy run in pass-through mode. By default, Policies work like firewall rules, evaluated from top to bottom, and when a policy matches, the configured inline response on the Policy is returned in the Castle Risk/Filter APIs, halting the evaluation.
We've launched a big update to the Policies page in the Castle Dashboard. The whole experience has been re-designed to make it easier to get an overview of how your policies are configured, with trigger and action information displayed on the policy-card. In addition to this we've simplified how to create policies with arbitrary trigger conditions, without having to create segments first.
Today we're launching an improvement to the Castle Policies: the ability to remove items from lists whenever a policy matches. Previously you've been able to use Policies to automatically add items to lists, and that way be able to create powerful automation such as flows for trusting devices for 30 days when a user completes verification. Automatically removing items is useful e.g. in scenarios where you'd like to unblock a user based on additional verification.
Castle's real time decisioning APIs, the Filter and Risk APIs, were originally designed to be used in environments where the activity is initiated by the end-user using a rich client, such as a browser or mobile app. The main power of these endpoints is that the Castle Policy engine is invoked, which means that you can configure real-time, inline responses, as well setting up automations such as List actions or Webhooks.
After receiving feedback from some of you who uses the List functionality, we've added a small improvement to list item management in the Castle Dashboard. Whereas previously any existing items were overwritten, now you'll be given the choice to overwrite the item if it already exists. The main reason this is important is that you might have added useful context in the comment field, which would have otherwise been lost when overwritten.