There is a simple yet sophisticated permissions system accessible using liquid. This is the same permissions system that empowers personalization, and is available for utilization by template developers using a handful of liquid tags.
When discussing the permissions sytem, it is important to start with the fact that the permissions system utilizes a cookie to store the permissions that the user (or a developer) has allowed or denied along with some additional information. If a user with cookies disabled in their browser attempts to load a page, or if they clear their cookies before loading the page, the system will have no way of remembering which permissions they have allowed or denied.
Because the permissions are stored in a cookie, which by the nature of cookies is associated with a domain, if a sute has multiple domains each domain will by the nature of cookies have its own set of permissions - and therefore its own set of personalization information. If you are attempting to use the permissions system or personalization across multiple domains you will need to keep this in mind and compensate for it.
It is also important to note that, by default, if a user has not granted permissions the default state is denied. The only exception to this is the session permission, which may be set by default to "allow" in the site settings.
Finally, before digging deeper into the permissions system, keep in mind that it is possible for the template developer to utilize the permissions system in ways that were not intended or specifically designed by the Marketpath CMS team, and as such any use of the permissions system is the sole responsibility of the developer.
The permissions system is capable of saving values for a virtually unlimited number of permissions. Each stored permission has a name, whether the permission is allowed or denied, the date that the permission will expire, and an optional string value.
The expiration date and value do NOT depend on whether the permission was allowed or denied. In either case the permission will have an expiration date and may or may not have a value (depending on whether the developer assigned one or not).
Note that the permission expiration date indicates the date that the "allow" or "deny" will expire and should not be confused as the date that the permission will be denied. The difference is that a denied (or allowed) permission with an expiration date in 1 week will remain as it is until the expiration date and then will become "undefined".
All of the built-in liquid personalization tools rely on a special "session" permission. If session permission is allowed, the personalization tools will work. If session permission is denied, the personalization tools will not work.
If session permission is allowed, the value associated with the session is the client identifier. Changing the value of the session permission will have the undesirable consequence of resetting the client and session information without the benefits of resetting the client or denying session permission. Don't do it.
Do feel free to allow or deny sessions or change the expiration date ({% set_client_permission %}), or even reset the client ({% logout %}) as necessary.
To set client permissions, use the {% set_client_permission %} tag. This includes both allowing and denying permissions as well as setting values and expiration dates.
To remove client permissions as though they had never been either allowed or denied, use the {% unset_client_permission %} tag.
To check if a permission has been allowed or denied, or to check the value associated with a permission, use the {{ client_permissions }} object. (eg: {% if client_permissions.allow_thirdpartycookies %}{{ client_permissions.thirdpartycookies.value }}{% endif %}).
To grant or deny permissions using javascript, the developer will need to parse the "_mp_permissions" cookie. If there are multiple permissions allowed or denied, they are separated by the '|' character. Each permission is represented as a series of values separated by the '^' character. The first value is the permission name, the second value is '1' if the permission is allowed or '0' if the permission is denied, the third value is the date the permission is set to expire, and the final optional value is the value that is saved along with the permission.
An example permissions cookie value without any additional permissions might be something like this:
"session^1^9/25/2068 7:56:21 PM^44444444-4444-4444-4444-444444444444" Read: The user has allowed the "session" permission. Their allowance for sessions will expire in 50 years. The value of the session permission is 44444444-4444-4444-4444-444444444444 (their session identifier).
If the developer were to add an additional permission for third part ads, the cookie value might look like this:
"session^1^9/25/2068 7:56:21 PM^44444444-4444-4444-4444-444444444444|thirdpartyads^0^9/25/2019 7:56:21 PM" In addition to the previous example, this signifies that the user has denied the "thirdpartyads" permission. Their denial for thirdpartyads will expire in 1 year.
Note that while a developer may modify the permissions cookie using javascript, if they set the cookie to an invalid format the effect could cause the system to forget all permissions just the same as if they had removed the session cookie altogether.