What is the right way to set deny function? about permissions2

[siredwin]

That is clearer now. Much appreciations.

[xyproto]

There was an echo example, until the echo package was changed by the echo developers, so that I had to rewrite the example.

I'm not sure if the old code is helpful for the latest version of echo, but it is here:

9221b1e#diff-04c6e90faac2675aa89e2176d2eec7d8L629

The main idea is to reject by just returning without serving any further content to the client, except perhaps an error page.

[siredwin]

Thanks for the reply.
I was able to get it to work but i still don't understand the default behavior.
Does my user need to be logged in as admin before trying to access the /admin page?
Currently, i am trying to have any users login in the /admin page and it is by default denied if i don't perm.Clear().

[xyproto]

Yes, by default, a user must be logged in as admin before being able to access URLs starting with /admin.

This is covered here: https://github.com/xyproto/permissions2#default-permissions

I could change the wording from "has admin rights" to "requires admin rights" and move that block of text to above the top of README.md, if that would be clearer?

[siredwin]

I think i may have closed this too early. I had an idea on how i would create my admin but i think i might have to change that now. I already implemented a regular user signup and login.
How do you recommend or how did you envision a website would create a regular user, and admin users using maybe on sign up form and maybe one login form?
I am having a bit of design block. What are your recommendations?

[xyproto]

One possible flow is this:

• User registers username, password and e-mail on a public https://website/register page.
• An unconfirmed user with a unique confirmation code is registered in the user state.
• The user receives an e-mail with a link to https://webpage/confirm/<unique confirmation code>
• When the confirmation page is visited, the confirmation code is looked up in the user state, and the user is marked as confirmed if found.
• The user is then redirected to the public https://website/login page.
• The user fills in username and password, and is then given user rights in the userstate.
• Once logged in, various menus and content appears, among them the possibilities to:
  • Change the password
  • Log out
  • Delete the account
  • Change username and other details
• Additionally, for registered users which has also been given admin status server-side (not through the web interface), the following menu options could appear:
  • Toggle admin status for other users
  • Reset passwords for other users (which triggers e-mailing a new confirmation-like e-mail to the user, marking the user as unconfirmed and with a unique confirmation code and and a link to a dedicated page for marking the user as confirmed again, and for changing the password)
  • Change passwords for other users
  • Delete accounts
  • Ban accounts for a certain period
  • Log any user
  • View basic user info
  • View metrics for password quality
  • Detect break-in attempts and unusual login patterns
  • The ability to send a quick message to any user
  • Manage user tags (a different take on user groups)
    etc

The possibilities are endless! :)

I am in the process of brushing up an old register + login application I created before I started developing on Algernon instead, where the same things can be done as in Go, but in Lua.

The nice thing about using Go + Go packages is that it feels more modular and "bottom up", though.