A Deeper Dive Into Lava and Entity Security

This article is a bit more technical than usual. If you don’t fully understand the details, don’t worry. We recommend sharing this with your Rock technician or partner, especially if your organization has custom features involving Lava entity commands.

Rockʼs security model is changing in v17. If your custom Lava uses background checks, keep reading to learn how these updates might affect your logic.

Security can feel intimidating, but understanding it is essential to keep your Rock instance functioning properly. In this article, we’ll clarify how security checks work in Lava and highlight how upcoming changes could affect custom implementations. By being proactive, you can ensure your Lava remains secure and operational as Rock evolves.

Lava and Security Checks

When a Lava administrator creates custom content using Entity commands, the Lava engine automatically verifies the viewerʼs security permissions for the related entity. For example, hereʼs a Lava snippet that displays background check statuses on the standard person profile page using the backgroundcheck entity command:

{% assign personId = PageParameter['PersonId'] %}

<h5>Background Check Statuses</h5>
{% backgroundcheck expression:'PersonAlias.PersonId == {{personId}}' sort:'CreatedDateTime' %}
    {% for bc in backgroundcheckItems %}
            {{ bc.CreatedDateTime | Date: 'yyyy-MM-dd hh:mm' }}
            {{ bc.Status }} <br>
    {% endfor %}
{% endbackgroundcheck %}

In this example, Rock checks the security of the BackgroundCheck entity type. Until now, this entity type used a global default, which allowed all users access. Since the page itself is typically access-controlled, this setup is usually fine.

Upcoming Security Changes

As part of the development of NextGen Rock, including the v2 API, we're improving where each Entity Type inherits its security, and in some cases, we're shifting away from the global default of "Allow All Users" to more restrictive defaults.

Using the example above, if an update removes the Allow All Users permission, your Lava would stop displaying background check statuses unless additional steps are taken.

Although we've focused on Background Checks in our examples, similar changes are being made to other entity types that typically don’t require security checks (aside from Lava entity commands). While these updates shouldn’t affect most situations, if you use custom Lava entity commands, you should review and monitor them after the update.

If you are participating in NextGen Check-in testing, note that security settings for many v2 API controllers will also be updated. If you've made custom security changes to these controllers, you'll need to review them again after the update.

When these changes occur, the Rock Update will include a "Heads Up!" notice linking back to this blog post so you can take any necessary action.

How to Address These Changes

To ensure your Lava continues to function:

Add Specific Security Permissions: Apply custom security rules to the BackgroundCheck EntityType. This is generally not recommended unless you really know what you are doing.
Disable Security Checks in Lava: Use the securityenabled:'false' option in your Lava entity commands to bypass security checks entirely.
- If you choose this option, ensure the page itself is properly secured to restrict access to the appropriate audience.

Hereʼs an updated version of the Lava snippet using the second approach:

{% assign personId = PageParameter['PersonId'] %}

<h5>Background Check Statuses</h5>
{% backgroundcheck securityenabled:'false' expression:'PersonAlias.PersonId == {{personId}}' sort:'CreatedDateTime' %}
    {% for bc in backgroundcheckItems %}
            {{ bc.CreatedDateTime | Date: 'yyyy-MM-dd hh:mm' }}
            {{ bc.Status }} <br>
    {% endfor %}
{% endbackgroundcheck %}

By staying informed and proactively updating your security configurations, you can adapt to these changes and ensure that your custom Lava and API integrations remain secure and functional.