We provide the Liquid for Sign Up, Login and Password Reset Forms and for checking if the current User is signed in
In this Article we'll provide the Liquid which can be used to manage access to Secure Zones. It can be used across most Liquid Files (excluding emails).
<div data-gb-custom-block data-tag="-" data-0='login_form' data-1=', layout: ' data-2='default' data-3=', redirect: ' data-4='/'></div>
<div data-gb-custom-block data-tag="-" data-0='form' data-1='form' data-2='1' data-3='1' data-4=', layout: '></div>
This is the same syntax for inserting a custom Form, where the id parameter should be the id of your Form. See the section Creating a Sign Up Form to learn more.
Once you have created a Form, you can select the Form from Toolbox and it will dynamically fill in the ID for you.
<div data-gb-custom-block data-tag="-" data-0='logout_button' data-1=', layout: ' data-2='default'></div>
The recover password form is the first step in recover password flow. Users should be presented with this form as they first realise they've forgotten their password. Completing the form sends an email to the provided address containing next steps.
By default, a system page will already be created on your site at /system/recover-password
, which can be found in Admin under Site Manager/System Pages
. You can edit that page, or add the form to a new page with the tag:
You can find and edit the Password Reset email in the Siteglide Admin under Site Manager/System Emails
It must contain a link to the dynamically generated URL: {{context.exports.reset_password.data.reset_password_url}}
.
This will be the system page /system/reset-password
with a dynamically generated token attached as a parameter.
This is the last step in the recover password flow where the user has already clicked the link in the email. If the token in the link is correct, they will be able to complete the form and their password will be changed.
This form should normally be outputted on the /system/reset-password
System Page, as this is where the dynamic link from the email will point. You can optionally redirect users back to the page where they can sign in with their new password.
These Liquid tags can be outputted in most contexts to get you quick information about a logged in user. They are not currently supported inside emails.
This will show you how and help you decide if using a dynamic single Form or multiple Forms is right for your Use Case.
This Article is written for Secure Zones version 1.2.0. Some of the contents may not apply to earlier versions.
Secure Zones are a useful tool for managing which Users will have access to content on a Site.
To give a User access to one or more Secure Zones, you can attach Secure Zones to a Form. The default behaviour is that a Form will Sign Up a User to all the Form's Secure Zones.
However, it is possible to change this behaviour using a hidden field on the Form Layout. This hidden field's value will by default contain all Secure Zones attached to the Form, but can be modified to contain only a sub-set of those Secure Zones.
Note
The hidden field cannot contain a value of a Secure Zone unless it is also attached to the Form.
If you wish to add single or multiple Secure Zones to a Form and have all those Secure Zones applied to the User with a single Form submission, this continues to be default behaviour and you don't need to do anything different.
You can also remove the hidden field from your Form to keep the default behaviour and avoid any front-end changes: <input id="s_sz_id" value="55665" type="hidden">
In this example, let's assume you have the following Secure Zones on your Site:
Public UK
Public USA
Private Employees Only
In this example, we want any Users to be able to complete the "Public Sign Up" Form.
Users filling out this Form will choose their location and we'll automatically change the Secure Zone to match either "Public UK" or "Public USA" depending on their preference.
We do not want ordinary Users accessing the "Private Employees Only" Secure Zone, so we want to be able to exclude this from the options and prevent malicious Users from manipulating the Front End code and gaining access.
In the configuration for the "Public Sign Up Form" in the Siteglide Admin, we can attach the public Secure Zones to the Form: "Public UK" and "Public USA".
By default, the Form will assign Users to both these Secure Zones, but we'll change that later.
The important thing at this stage is that we have not added "Private Employees Only" to the Allow List.
Thanks to this choice, malicious Users with knowledge of developer tools and JavaScript will not be able to manipulate the Public Form to add them to the "Private Employees Only" Secure Zone.
A malicious User from the USA may use Front End code to Sign themselves up to the "Public UK" Secure Zone, just as a malicious User could be untruthful on a Form. But by attaching both Secure Zones to the Form, the Partner or Client is making a clear decision that these "public" Secure Zones are both safe. By safe, we mean nobody will see content they shouldn't if they complete this Form- even if they switch to another zone.
It is the responsibility of Partner and Client to make sure that if a User has access to a Form, that Form only has Secure Zones attached that it would be safe for that User to access.
In this example, we'll use a Form Field to provide User Input which will change the active Secure Zone dynamically. This is optional, as you may have other reasons for assigning a particular Secure Zone.
In order to dynamically assign Users to the correct public Secure Zone, we'll need to create a custom Form layout.
A quick tip for setting up the Custom Layout quickly is to start by copying and pasting the content of the default Layout.
In the code from the default Layout that we've copied, we can see the dropdown field that my Users will use to select their location (and thanks to the code we will write now, their Secure Zone).
We can also see the hidden field that we must change the value of in order to change the active Secure Zone: <input id="s_sz_id" value="743,744" type="hidden">
Note- this includes the IDs of the Secure Zones, not their names, so Admin should be referenced so that you know which is which.
The JavaScript will need to select the "#form_field_12_1" element, watch for a change event and then select and change the value of the "#s_sz_id" element.
Field Name
Liquid Tag
Description
is_logged_in
{{context.exports.is_logged_in.data}}
true/false (boolean), the value is not stored as a string. Used to determine if the user is logged in or logged out.
Current User First Name
{{context.current_user.first_name}}
Outputs First Name of User currently signed in
Current User Last Name
{{context.current_user.last_name}}
Outputs Last Name of User currently signed in
Current User Email
{{context.current_user.email}}
Outputs Email Address of User currently signed in