Creating limited access sub-site without need to create account

(Edinkin) #1

Hi everyone. Looking for ideas / best practice.

We are trying to work out a solution to allow known group of people access to section of the website without the need to create a user and manage logins and passwords. The section would contain few pages and files. We do have user emails. We are not after anything ultra secure. The information in this sub-site/folder is more of a way to collaborate on documents and place to put documents linked to email campaign etc.

Due to network restrictions other collaboration tools are not available to all people who would be accessing this, but they all have access to our site.

Has anyone done something like this before?
Thank you for your thoughts.

(Tbaatar) #2

The best is to place these resource under a new site with new domain or sub-domain and hide it from the internet from being crawled with link type 2, robots.txt disallow and meta tag noindex.

You could also use globals GET parameter to display the body of the content so that it only works as a link similar to Gdoc shares.

https://www.somewebsitename.com?access=shared

(Edinkin) #3

Thanks @tbaatar I was thinking along those lines, the slight complication is that we have around 30 of these and creating sub site for each of these isn’t practical I suppose they can be “folders/pages” under same site. Each of these 30 has they own group of people already registered. Most of these people are health professionals and are extremely busy, have so many logins that they get password fatigue and looking for email with some specific link is daunting. Anything we can do to make it easy for them to access this while maintaining some security is worth doing.

I am wondering if there is a way to have a form where people would put they email address in, and system would match they email with one of these 30 and send them a link like you suggested above. As I mentioned we already know they email addresses and registration process is separate.

(Tbaatar) #4

This should be possible with Search Page asset and a Standard Page (optional).

1/ HTML Search Form
First create optional Standard Page with simple input for email search with POST to the Search Page.

<form enctype="multipart/form-data" action="/dev/users/search-user" method="post">
<p><input type="text" name="user" placeholder="input your email address" /></p>
<p><button name="submit" type="submit">GET DOCS</button></p>
</form>

2.1 / Search Page: Search Fields

  • Name: anything e.g staff
  • Type: asset attribute
  • Details: asset type: user and attribute: email

2.2 / Search Page: Details Screen

  • Root Nodes: To all or specific user group
  • Asset per page: 1
  • Stored Query Location: Select the name of Search Field with Post Variable Name, in this example user (same as the standard page input field name)
  • Stored Search Options: Results page

2.3 / Search Page: Default Type Format

This is optional if the user(s) is found by the search so you can display the links or docs. But it can be used as secondary way of validating the search email matches the result and then display the items.

<p>Hey %asset_attribute_first_name%</p>

%begin_frontend_asset_attribute_email^eq:{globals_get_user}%
<p>Access to wonderful things.</p>
%else_asset%
<p>Oops, we don't recognise you.</p>
%end_asset%

The reason why I prefer to use Standard Page to perform the search as opposed to just doing it with the Search Page itself is because if you have Analytics or any tracking tools the results of the page in the URL parameter gets indexed so by using POST the email is kept hidden.

(Bart Banda) #5

If you don’t have proxy caching in place, you could try using the https://matrix.squiz.net/manuals/triggers/chapters/trigger-actions#Join-User-Group-for-Session trigger action as well to join the public user under a user group temporarily if they hit some secret URL or similar.

I’d also recommend connecting to an external auth system using the SAML or OAuth2 account managers so that your users can use existing accounts such as Facebook, Google, LInkedIn or others if you don’t want to worry about them having to create more user accounts.

(Edinkin) #6

@tbaatar Thanks for ideas. While we have emails of users they are not users in the system, but I might be able to adapt this code to something like data asset.

(Edinkin) #7

Thanks Bart vast majority (more than 90%) of these users are in the same health.nsw.gov.au domain, they are not likely to use these emails for external networks. It would be great if health had a SAML service, but we not there yet.
The complexity of it comes from the fact that these groups are mixed between @health and external otherwise I would put it all on intranet and problem solved.