feat(examples): auth pattern exploration

[n0izn0iz]

WIP

Authentication pattern using auth token objects

• p/demo/auth: core interfaces
• r/demo/subacc: example auth provider that allows to create sub-accounts.
  To implement an auth provider you only need to create new auth.Token and auth.AuthenticateFn implementations
• r/demo/sessions: another example auth provider that allows to whitelist addresses that can act as the mother account
• r/demo/authreg: auth providers registry, allowing realms to manage ressource for any authentifiable entity
• r/demo/authbanker is a basic example of allowing to manipulate coins with auth tokens

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 The pull request was created from a fork (head branch repo: n0izn0iz/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[moul]

Can you write a txtar or share a few maketx calls that you expect to use with this?

[n0izn0iz]

There is an integration test here

[n0izn0iz]

Also added txtar here

[moul]

What prevents me from creating my own authenticator? I don't understand where you expect to whitelist the approved authenticators.

[n0izn0iz]

Nothing, the pattern is meant to be extendable.

The registry namespaces the authenticators so you can't authenticate an entity from an other authenticator.

How would you exploit this?

[n0izn0iz]

Actually there was a vulnerability in namespacing if you pass paths with .., maybe you were refering to that? I added a guard against that here

[n0izn0iz]

Also if you want to whitelist providers somewhere, you can check the token's Source or statically import the providers and call their Authenticate function

[moul]

I was considering creating a new authenticator, registering it, and then using it for universal acceptance.

I see two secure approaches: one is to implement a whitelist system on the registry itself, and the other is to establish a whitelist system within the contract that checks the authentication.

However, allowing anyone to create an authenticator and contracts to simply "verify if a token is valid" is definitely insecure.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[moul]

I suggest you continue exploring this authentication pattern. Meanwhile, I will consider patterns that are more user-friendly with simple maketx commands, ideally without needing to create hashes or long strings.