The auth module is invoked by the core prior to rendering any page request to confirm the user is allowed to view the page. One of the goals when building triki was to ensure content could be secured and shared selectively with specific groups of people. More than this, a page can be public but have group specific parts. For example say a holiday album shows only public photos by default but private photos are also shown to friends.

This is core principle in the architecture of triki and ensures your content is completely under your control.


In order to authenticate, users can optionally log into a website. By default, each user has a login and password which is controlled by the administrator. This is simple but not ideal because user's need to remember yet another username/password in order to access your website.

To address this, triki has recently been integrated with web sites that provide OAuth identity verification. Many popular email address providers, like GMail, Yahoo and Outlook support OAuth which allows websites to offer the 'Login with ....' buttons. These verify your identity with the selected site and then return you to the original website.

triki support OAuth, ideally the openidconnect variant, in order to acquire the identity of the signed in user. This ensures that users can login once and simply use that login across your triki site, and any other site.


Users are added to your graph via the web console studio. By adding an email address to the user, it is associated with the verified email address via the OAuth login above and then permission to pages granted on this basis.

If it is just a site-only user, then no email is required and password will be sufficient to authenticate the user.


Groups have two meanings in triki. First they are used to define the groups that user can be a member of. There are some default groups like Administrators which gives a user administator access. Additionally users can add groups of their own to define users who should have similar access levels in your website.

The second way groups are used is by assigning a restricted property to a graph node, and hence a web page. When a page is then requested, the user permissions are matched against the page permissions to see if the page can be rendered.

All pages must have at least one group. If the page is open to the public then it can simply be assigned to the public group.

Node-Level Permissioning

When rendering a page, it is possible to view all properties associated with that page, which might include the title and date created. A node may also be linked to other nodes in your graph. For example, the a page to that shows a photo Album, may also show thumbnails of photos in that album. Triki will check the permissions on the related nodes (i.e. the photos) to confirm the user has permission before rendering that part of the page.

This means that the same page can have different views depending on the profile of the user viewing the page. And all this happens by default, because all nodes must have a group restriction.

Node-level permissioning is a powerful and fundamental feature of triki that is gives fine-grained control of how pages are rendered.