-
-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add role based output (think membership sections, RBAC) #5139
Comments
Yes also have to consider pages which bear no "user" version and which are solely available to members (certain roles). This could be as simple as adding a
|
At first glance, Couldn't the structure be handled already with |
@talves I'm sure it may already be possible using unrelated features and hacks, but what Bep is proposing here is a "supported" feature along with documentation and a defacto "best practice". I can sense a lot of people will be glad to let the markup (Hugo) handle this "role" conditional and publish dir structure rather than relying solely on another part of the JAMstack. |
@regisphilibert Yes, I get it. |
What I have in mind isn't currently possible with Hugo. You may achieve something similar (I think Custom Output Formats may come closest), but even then it would be a band-aid solution you're not ... trusting. For membership type of information, some information leak between sections may not be too bad, but in many situations when you want to introduce role-based access, you want a well-tested and ... secure solution. |
👍 Very interesting and promosing, and another reason for many to move away from WordPress and Co.
Are you thinking of JavaScript or anything third party dynamicish? |
My sentence above was targetted at a "Custom Outputform home made" variant of the above. But also, doing this with a fine-grained JavaScript/JWT rendering logic is 1) Hard to implement but also 2) Hard to verify/test. With my proposal you still need authentication -- but the authorization part is on a very coarse-grained level. Apache/htaccess etc. would get you very far. And having these "role file sets" on disk before you publish means that you can do "static security audits", so to speak. On some level, it sounds too simple and a little bit stupid to actually work. But the simplicity has many nice features that I like more and more when I think about it. |
This has legs, big time... Imagine the combo of something like Auth0 + Hugo tokenised content delivery could be rather sweet. There's obviously a lot to think through here but I'm liking the way your (great) mind is whirring on this one. |
Here is something using Auth0 from @biilmann https://github.com/biilmann/auth0-example |
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. |
Hope this is kept. |
Yes, this is still a really good idea. |
Yes! An easy way to achieve this would be so sweet and welcome. |
I agree more and more. I saw a blog post from Netlify about "how to use GatsbyJS for real application" (not sure what the title was exactly), which in some steps showed how you could add authentication to a site and then use the credentials in Netlify functions. I think that was the gist of it, but my main thought after reading that was:
So, while my suggested approach to this may look almost too naïve to work, but the mental model is extremely simple, and the added cost is almost entirely build time (I think Hugo could pull that off if we are smart). A "membership site" with lambda functions or similar isn't realistic for anyone with a limited budget, and even then it sounds suboptimal. |
I'm not yet using Netlify, but it appears that for the free level, there are add-ons if you need more than the 1000 identity users included for free. It would be 99 USD / mo for 1001 to 5000 users. Otoh, Auth0 free level allows 7000 users for free. They both have different constraints. Anyway, the assumption with those is, at some point, it's going to cost. I'd rather find a forever-free or nearly-free way to do it, for a small site. It would also be nifty if, your "s3deploy" could be made to deploy as needed, i.e. to whatever buckets map to whatever role, etc. See also: https://github.com/jsonmaur/lambit (yet another node app but...maybe good for reference assuming lambda@edge) |
There are some fairly concrete plans (if you watch the PR list) on getting a tool with a similar feature set of I have not done price calculations of the above, but In my head, the expensive and complex part in the "existing model" would be the dynamic fetching/authorization of content:
You would some way to map users to role(s), which is not described above. The natural thing would be to use "some authentication provider" that supports this, but for simple setups maybe Hugo could maintain a simple mapping ("bjorn.erik.pedersen@gmail.com => admin") and provision some "lambda storage" ... Me thinking out loud. |
Interesting! If it could be made to work to keep that mapping in a json data file, then managing it could be done anywhere you like, and, you could likely simply script a [
{
"bep@gmail.com": "admin",
"randoman@gmail.com": "user",
"baddie@hak0rz.com": "none",
...
}
] |
Yes, but not very dynamic. But it obviously could work for some use cases. But note that Hugo can not use that "role map" directly. We are a static site generator, so any role validation must happen in the "lambda router" (or something). |
Hey guys, did we do anything on this? I'm desperately looking for a solution. I love Hugo and I don't want to switch to say Gatsby, which actually does it see https://www.gatsbyjs.org/tutorial/authentication-tutorial/ |
@lionzan no, but note that this issue is mostly about authorization; Gatsby does not provide a (static) way of doing that? |
@bep thanks. I'd be totally new to Gatsby if I ever started to explore it, that's what I was pointed to as an example to manage RBAC on a site built with one of the stacks integrated with Amplify. I was thinking I could use insertHTML getting the content to be inserted from specific folders under /static/ depending on the role of the user, and limiting access to the folders to specific roles. This would of course require me to create some additional files and folders under /static/ in some other way not directly controlled by Hugo. Does it make any sense? Or am I missing some crucial aspect? |
I cannot answer that without writing a novel. I read your link again, and it mostly talks about authentication -- which is the simple (relatively) part of all of this. The small part about presenting "user based" content is very much dynamic -- and not remotely similar to the static role based setup outlined above. |
I think that the authentication part is relatively straightforward with AWS cognito which integrates perfectly with Amplify. |
If you read my first post in this thread, you will see that I don't agree about this. I think this will be a big win for typical membership portals (small newspapers etc.). |
Yes I read it, when I say beyond the scope of Hugo I mean it "right now" and I agree with you that it should be a capability of Hugo. My problem is that I want to do it now, not wait till your proposal is implemented and integrated in the system. As it stands, Hugo has no dynamic capabilities whatsoever as far as I understand, but I might be wrong. (actually from what I read in your profile, there's no way you can be wrong when talking about Hugo! Thanks for developing it!) |
I am not sure where we are on this, but eleventy seems to have an interesting approach. https://github.com/11ty/demo-eleventy-serverless-oauth |
@mireille-raad I don't see any mentioning of roles in the above links? |
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
htaccess
with Apache. Configuration can be managed and generated by Hugo, but you need to map that model yourself.or Netlify Access Control or you build your own using the mechanisms in AWS
The downsides of the above are
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:
home.member.html
.{{ if .Site.HasRole "member" }}{{ end }}
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:
The above will solve both
authorization
(you need to be a member to have access to resource x) andpresentation
(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.
The text was updated successfully, but these errors were encountered: