Skip to main content

Create a public page

Depending on the purpose of your application, you may want to make one or more of your webpages public. For example, if you are building an application to allow customers to order products or book services, you may want to make your homepage and the views containing details of your products or services visible to anyone so that prospects can view them without first having to sign up for an account and log in to your application.

To make a view public so that visitors do not have to log in to view the content, you need to:

  1. Make the relevant casetype public. This could be a standard casetype or a page casetype.
  2. Grant unauthenticated users permission to see the widgets included in a view for the casetype.
  3. Grant unauthenticated users permissions to see relevant menu items in the navigation bar.

Depending on your application, you may also want to grant unauthenticated users permission to perform certain activities from a public page.

Make the casetype public​

By default, both standard casetypes and page casetypes are private. This means that anyone attempting to access a URL for a case (such as https://my-application.grexx.today/case/1:1235:1 or https://my-application.grexx.today/home) is automatically redirected to the application's login page.

If you make a casetype public:

  • The views for that casetype are accessible to anyone with the correct URL without logging in to your application.
  • The activities belonging to that casetype can be made available to users that have not logged in to your application.

This applies to both page casetypes (such as the homepage) and standard casetypes (such as products or services).

To make a casetype public:

  1. From the Studio, open the relevant casetype.
  2. At the top of the page click the pencil icon to open the Edit casetype dialog.
  3. Open the Advanced tab.
  4. Select the Public option and then click Submit.
Tip:

Although anyone can access the views for public casetypes, by default they cannot see any of the content that those views contain. Unless you grant unauthenticated users permission to see widgets and/or navigation items, all they will see is a blank webpage.

Allow unauthenticated users to see content​

When you configure a view for a page or standard casetype, you grant user roles permissions to see each widget in the view. This means you can give some user roles permission to see all content, while restricting other user roles to a subset of the content. For example, you might want to grant logged in users permission to view all widgets on your application homepage, while limiting visitors that have not logged in to a few widgets that display high-level information (such as a map showing available services or tiles displaying product details).

An alternative approach is to create multiple views for the same casetype: one for logged in users and another for visitors that have not logged in. This is useful if you want to create two very different experiences.

You can grant permissions to anyone that is not logged in to your application using a special platform role that identifies Not authenticated users. Two such roles are available by default:

  • Authenticated and not authenticated user identifies all logged in users and any visitors that are not currently logged in. This is useful if you want to give everyone permission to view content or perform an activity.
  • Not authenticated user only identifies visitors to your application that are not currently logged in. This is useful if you want to display different content to non-logged-in visitors and logged-in users.

To make content visible to anyone that is not currently logged in to your application:

  1. From the casetype, open the relevant view.
  2. Select a widget to display the widget properties.
  3. At the bottom of the properties pane, use the Rights list to select the relevant platform role.
  4. Ensure your changes are saved.
Note:

Granting unauthenticated users permission to see widgets also makes that content visible to web crawlers. If you do not want the public content to be included in search engine results, create an SEO & metadata profile for Robots metadata, set the value to noindex, and apply the profile to the relevant views. For more information, see SEO & metadata.

Allow unauthenticated users to see navigation items​

Depending on your use case, you may want to make some or all of your application's navigation items visible on public pages. When you configure a navigation bar, you grant permissions to view the bar itself and on each menu item on the bar.

You can give visitors that have not logged in permission to see the same navigation bar and menu items as logged in users. To do this, grant rights to Authenticated and not authenticated user. If an unauthenticated user navigates to a webpage that they do not have permission to see, they are automatically redirected to the login page. This is useful if you want to prompt visitors to log in to your application when they try to visit certain pages.

Alternatively, you can grant unauthenticated users permission to view only the menu items for pages that they can access without logging in. In this case, you may want to include a Log in link menu item so that visitors can log in to access other parts of your application. Grant rights on the Log in menu item to Not authenticated user so that it is only visible to visitors that have not logged in.

If you have created a dedicated view for unauthenticated users, a further option is to create a separate navigation bar for use with that view. This allows you to manage the navigation separately and is useful if the public-facing aspects of your application are very different to the pages for logged-in users.

For more information about setting up a navigation bar, see Add a navigation bar to your application.

Allow unauthenticated users to perform activities​

You may want to give unauthenticated users permission to perform certain activities. For example, you may want to allow visitors to your site to generate a quote or make a booking request without having to create an account or log in first.

You can make activities available to unauthenticated users from a view. For example, you can use an activity widget to display the form for an activity on the current case. Ensure you grant unauthenticated users permissions both to view the widget and perform the activity.

You can also make activities from another casetype available to unauthenticated users from a public page or view. For example, you might use template widgets to display buttons so that users can initiate optional tasks. Ensure that the casetype to which the activities belong is public, and then grant unauthenticated users permission to perform the activities and view the widgets on the public page.

For more information about adding widgets to a view, see Configure pages and views.

Add CAPTCHAs to public activities​

If you make an activity available to unauthenticated users on a public page, anyone can perform the activity. This includes malicious automated scripts or "bots" that are designed to disrupt your application by creating fake accounts, submitting spam data, and/or artificially increasing the load on your application. To reduce the risk of bots performing public activities and generating spam, you can add CAPTCHAs to your public activities.

CAPTCHAs ("Completely Automated Public Turing test to tell Computers and Humans Apart") are automated tests that determine whether a website visitor is a human or a bot. Grexx Platform uses the CAPTCHA provided by Cloudflare. If a CAPTCHA determines that a visitor is a bot, they are prevented from performing the activity.

Tip:

If you have configured a custom hostname for your application, you will need to create your own public and private keys in Cloudflare and then upload them to the security settings for each environment in MyGrexx.

To add a CAPTCHA to an activity:

  1. From your Studio open the relevant casetype and select the activity.
  2. From the bottom right-hand corner, open the hamburger menu and select Edit captcha.
  3. Select the type of CAPTCHA you want to use:
    • Managed: The user must select a checkbox.
    • Non Interactive: A loading bar is displayed while the browser is busy.
    • Invisible: The user is unaware of the CAPTCHA, which runs in the background.
    • Custom: Select this option if you have configured a custom hostname and have uploaded your own CAPTCHA keys to MyGrexx.
  4. Select the theme you want to apply to the CAPTCHA. To apply custom styling, add your CSS to the Custom theme box.
  5. Click Submit. The CAPTCHA is applied to the activity.

For more information about how the available CAPTCHA options distinguish humans from bots, refer to Cloudflare's documentation.