Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
How to create a Secure Zone using GraphQL via the CLI
Secure Zones are simply a Model object within Siteglide, with this in mind, we can very easily create Secure Zones via the CLI using GraphQL.
You have installed the Secure Zone module on the instance
You have setup CLI and connected to your Site
You know how to use the GraphiQL editor
Below is the GraphQL mutation that is used to create a Secure Zone from Siteglide Admin.
We simply pass it the name for the Secure Zone within the query variables.
After running the mutation, you will see an ID returned in the output window of the GraphiQL editor. The ID returning means that the mutation was successful and your new Secure Zone can now be used.
Note
If you already have Admin open you will need to refresh it to see the new Secure Zone.
This article for developers helps you get more out of Secure Zones, as you can output basic information about the Current User dynamically.
You have installed the Secure Zones Module
You have added a User Sign Up Form
A User has logged in
When a User signs up or logs into your site, we store basic information about that user. You can use this to make the page respond uniquely to that user.
Outputting the following liquid on the page shows the full range of fields available:{{context.current_user | json}}
You can traverse through the fields in the object and output them with dot notation. E.g. {{context.current_user.first_name}}
This will output the current user's first name, so you can say hello.
You could also use an if statement to run logic using this. E.g. If I want to say hello to all users with a siteglide email address:
You can see any Pages/Items that are already in the Secure Zone:
To add more items go to a specific Page or Item and add it to the Secure Zone (e.g. a Page has the Secure Zone section at the bottom of the Details tab):
You can also see what Users are assigned to this Secure Zone:
Again, you can add Users to a Secure Zone by going to a specific User in the CRM:
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