hugo icon indicating copy to clipboard operation
hugo copied to clipboard

Add role based output (think membership sections, RBAC)

Open bep opened this issue 6 years ago • 27 comments

Note that this proposal isn't a "ready to implement" one. These are some initial thoughts. And these thoughts skip the parts that live outside of Hugo (authentication etc.).

The current options for this with Hugo include

The downsides of the above are

  • It can be very complex and potentially very expensive
  • It only allows you to allow or restrict access to a set of resources, i.e. URLs. E.g.: "You have to have the role MEMBER to view pages below /member", "You have to be ADMIN to view pages below /admin" etc.

If you want to, say, show a different home page for members, you will have to go the cumbersome route of somehow building your pages with secured server-side services. Which partially removes the static part and you end up with some ... jam.

This proposal is simple:

  • Add Role as a new concept in Hugo
  • There should be a Role hierarchy
  • It should be possible to override templates for a given role, e.g. home.member.html.
  • It should be possible to do role membership checking in the template: {{ if .Site.HasRole "member" }}{{ end }}
  • A way to restrict output for roles.

The above is simplified. There are some questions on how to do this effectively with many roles to avoid duplication etc., but in it's simplest form with 2 roles you may end up with something like this:

site
└── public
    ├── member
    │   └── index.html
    └── user
        └── index.html

The above will solve both authorization (you need to be a member to have access to resource x) and presentation (if not a member, show the registration link).

The above would still need something outside of Hugo to do the switching (possible solutions include Cloudflare Workers or Cloudfront Lambda@Edge). But the above is a much simpler model to reason about than what we have today. You could possibly set up a Amazon S3 bucket per role?


Some additional notes:

Adding roles as a front matter attribute to restrict access would work and would be the to go for many situations, but it would not be very convenient for "big" sites, and it would also not cover static assets.

So I suggest that we also add some "access patterns", e.g.,´/members/**` etc.

bep avatar Aug 30 '18 06:08 bep