Some Velo API methods are restricted based on the identities and roles authorized to call them. Elevation is a mechanism that allows you to call these restricted methods even when the calling identity lacks the necessary authorization. This process creates a temporary elevated version of a method by calling the elevate() method, enabling you to bypass the usual authentication checks that might otherwise restrict access.
For example:
Methods can be restricted based on user identity or roles and permissions.
An example of a method restricted by identity is the assignBadge() method. This method can only be called by Wix users because site members should not be able to assign badges to themselves.
This means that assignBadge() can only be called without elevation in a published dashboard page, where the caller will have the Wix user identity. In all other cases, if you need to call assignBadge(), you must elevate it first.
For example, you might want to automatically assign a badge to users who take some specific action or reach a predetermined milestone. Since the site members who earned the badge don’t have rights to assign it to themselves. In this case, you need to use elevation to assign the badge.
An example of a method restricted based on roles and permissions is the confirmBooking() method. This method can only be called by admin members with an administrative bookings role because users creating bookings should not be allowed to confirm their own bookings.
If you need to call confirmBooking() on behalf of a user who does not have an administrative Bookings role, you must elevate it first.
For example, you might have a specific service that you want to confirm automatically once a site visitor books it. Since site visitors who book the service don’t have permissions to confirm it themselves, you need to use elevation to confirm the booking.
Due to potential security risks, you can only elevate methods in backend code. While elevation offers flexibility, it’s crucial to consider how and when elevation is triggered. Web methods and HTTP functions are particularly vulnerable if not properly managed due to their open nature. Elevation in backend events or code only triggered from scheduled jobs presents less risk but should still be handled cautiously.
To demonstrate how to properly handle elevation, consider a site that rewards frequent visitors with a special badge. To do so, the code needs to track recent member visits and call assignBadge() using elevation when a member has visited frequently enough. (Note that the code samples below have been simplified, removing error handling and other non-essential code.)
Here is an example of an insecure approach to writing this code:
There are several problems with the assignBadge() web method used in this approach:
Because of these issues, this method can be called by a malicious user to assign any badge to any member.
You can easily remedy these issues by being more careful about where you use elevation and how you expose it to be called.
For example:
In this approach, the following makes sure the elevation is not exploited by malicious users: