Because I need a membership section. Nothing to do with Hugo. In fact, I want to announce I’m working on an open source CMS editor for Hugo, so I can go back with it as soon as I can. The goal is to be able to create and edit new posts through a CMS interface native to Hugo. I know Netlify currently offers a sort of CMS, but I want to make use of Hugo to make my own.
My two other projects, Edgar (Hugo for Networking) and MediaWiki Template (MediaWiki Template) are some of the best tools I’ve built for myself and I made them with Hugo.
Ghost looks nice, but also overly complex and somewhat outdated. It went from being a “just blog!” system to becoming a CMS, with newsletters and subscription capabilities. Since Hugo doesn’t handles members natively, I forcefully need to move away from Hugo for this project, but didn’t want to do it without first making the commitment to return later on to myself here.
I am too always annoyed when I have to buy a car to listen to my CD. So I can understand why you would want to move away from Hugo for your membership section. On the other side, in my experience, Hugo runs on my computer and I have some other programs on that computer too… Maybe it’s just the point of view that restricts you.
Well, is not a matter of me wanting to move away from Hugo, but having to. Tried to make the membership section work through aws auth but it wasn’t really something that goes well with Hugo, so I decided for Ghost. As far as I know, its the best alternative to ending up with something like Wordpress.
Hugo seems the future of the web to me. It is so flexible, I am actually using it as a db.
If I would have to add a member section to my Hugo website, as in:
check if person visiting a page is a member
check if person visiting is part of a member-group that is allowed to view this page
I would use either Netlify Identity or a solution based on WordPress (hehe, yeah) only for the login/out part that sets a cookie that my Hugo site can read and act upon.
The thing is, “checking something and delivering different content on page visit” is dynamic. Hugo is static. This is why I prefer the step back to re-evaluate what we need here Those solutions in the end tend to be easily “hackable”. If you check my login status via JS I can do a curl request to receive the page and then see, whatever JS method you use to hide content from me.
The proper solution to this is either a server-based functionality (Netlify Identity or something comparable from other providers) or a dynamic website. The main word here is “server-based”. Because only THEN you can be sure that the visitor to the page is not able to somehow circumvent your solution.
A very simple solution would be hosting your site on an Apache Webserver and doing registration of members manually by adding them into .htpasswd. Or even have the same password for all members.
Long story short: Hugo is great, if you use it to create a static website And for all other purposes, it is a solid foundation, but you probably want something else in that case.
Well, the CMS I’m working on for Hugo can be used from your website itself and spits out a .md file when you are done to whatever directory you have your pages. What you end up with is an actual CMS that feels as if it was part of Hugo, because it is.
I believe there must be a way of doing a members only section with Hugo by having a minimal setup that can be used with any framework, sort of a “standard”. Maybe with Zapier? Maybe a guideline to follow, very short, very minimalist that will yield in a member’s only area, so it can be replicated across many frameworks (PHP, JS, etc). So you will have a static part of the solution, and a very small part on a server side environment that does just a few things.
The more I think of it, the more it feels as something that can be done. The current solutions are, well… too complex. Needs to be simpler. That’s what I’m planning on doing.
I will be looking into that as soon as I’m done with the “CMS” (not really a CMS but, you know, post-editor would be a better name)
Here’s an experiment I did last year with a SEO plugin for hugo: Victor Hugo so yeah, the little bugger is pretty versatile and can be used for many things.
I have plans for this, and it may be closer than you’d think (I have been doing some thinking behind the scenes). We can certainly implement a concept of user roles in Hugo, which would create multiple versions of a site. You would still have to add some logic outside of Hugo authentication and URL redirection, but that would be a very thin layer of logic. I have written about this elsewhere, and I still think it’s a good idea.
And I read that post (or was it in the issues?) and am waiting for the “real thing” I am not convinced and wonder how this will work out. The thing is, that the way you describe it I could create it with current Hugo-functionality with a custom post type and some taxonomies. But how does that solve the authentication question? If I upload something on my server that only certain people are supposed to see then it requires some form of server-side assurance. Security by obscurity might work, but anyone knowing the URL/location of the content that requires a membership would be able to reach the location without server-side interference. I don’t think it’s Hugo’s job to take care of that. *mumble mumble pages from data is more important mumble mumble*
Yep, that’s what I was thinking as well. A very, very thin layer of logic. Paper-thin. But it should also have a very specific guidelines to follow for setting up the authentication. Something that can be replicated elsewhere, indistinctively if the user server runs on PHP, React, etc.
For instance, Ghost can only currently send out newsletters by using mailgun. Yes, Ghost is also open source, and one can code a solution for Ghost to send emails with AWS SES, for instance, but that requires a level of maintenance that not many are willing to commit to (especially when new updates start rolling).
Hugo’s authentication should remain as flexible as Hugo itself.
I assume Ghost has the same benefit that WP has – that they host everything themselves.
But if you want to do the “build it yourself” with Netlify or something, you end up with a fairly expensive and complex solution. From what I’m seeing it’s about delivering “membership content” via online APIs – which is on a totally different level cost wise and security wise compared to my simple model of having a super thin layer that routes members to /members and users to /users. You would certainly need an authentication provider and some way to manage the roles, and while I don’t expect the average Hugo user to build that, I certainly could if I wanted to start a … newspaper, and if the model is simple enough, there will be hosted alternatives for that part of the setup.
Not necessarily; what I was thinking was that for the secured pages (after the login), it would be enough to check if the user is authenticated or not through ajax (with a fallback to ‘enable your damn js, the planet uses js now!’). So for each authenticated page, there’s an ajax call, possibly a local storage setting being stored within the user’s browser as well, maybe even a token. Even if you know the protected URL, you won’t get past the API authentication check.
have you tried the netlify cms seems much better option and it is free, and really easy to customise works great with Hugo. I think it is the best cms for Hugo out there.
thanks
side note
I am a beginner to Hugo less than a year so do not base your decision on my experience. what I am trying to say is I use Hugo with netlify and it is really easy to use without any issues.
Or more advanced authentication with third party providers using oAuth:
These worker functions can automatically be deployed when using CloudFlare pages to build and publish your website, just put them in /functions directory.
Maybe we can create a deploy implementation for Hugo that comes with some standard functions for CloudFlare?
Forestry.io has a great CMS for Hugo. They are making a new CMS called Tina.io that might work for you and all the customizations you might want to add. Tina is an open source project as well.
Those solutions in the end tend to be easily “hackable”. If you check my login status via JS I can do a curl request to receive the page and then see, whatever JS method you use to hide content from me.