🚀 Auth feature launched. Let's talk about the last update !

[SebConejo]

Hey Manifest community! 👋

We’re excited to share some awesome progress with you all. Our journey toward the MVP is picking up speed, and the contributions from this amazing community are truly driving us forward.

🪪 What’s New in This Release?

Authentication Feature: We’ve rolled out a new feature that allows you to create authenticable entities and manage access with custom API rules. @mcoquet, we actually took your suggestion on board before diving into this one. Thanks for the input—this is exactly the kind of feedback that keeps us moving forward!

New Contributing Guide: We’ve updated our contributing guide to make it easier for new contributors to jump in. If you’ve been thinking about getting involved, now is the perfect time!

Instant Stackblitz Demo: Check out our new Stackblitz demo that gets you started in seconds. It allows to jump into creating a Manifest backend instantly.

🛠️ What’s Next?

We’re on track to deliver our MVP in a month! As we prepare to tackle the Validation feature, we'd love your input. Have thoughts or ideas? Share them with us by commenting this post, or directly on Discord!

🙌 Join the Conversation

This discussion is a space for you to share your thoughts, ideas, and experiences with the latest updates. So don’t forget to try out the new Auth feature. Your feedback is key! What do you like? What could be improved? We’re all ears!

Let’s keep the energy up and continue building something amazing together!

Links:

• Release information
• Documentation on Auth

Get involved

• Feature request
• Report a bug

[joeberetta]

Hey @SebConejo
Looks awesome

Could u please show the example of how to define restricted rule "only owner" can do action?

P.s. I found this project after small research of pocketbase.io but I'm not familiar with go and ur project looks awesome too

I'll give it a try in my pet project

[brunobuddy]

Hello @joeberetta

As of today the current Authorization system in Manifest is RBAC (Role-Based Access Control) which means that you can create several entities as roles (like User and Manager for example) and allow some actions only for an entity. Example: Users can only read items but only Mangers can create an item:

entities:
  Invoice:
    policies:
      read:
        - {access: restricted, allow: [User, Manager] }
      create:
        - { access: restricted, allow: Manager }
      

Thus there is no "ownership" concept in the current authorization system. In order to do that, we would need to implement an ABAC authorization. We have that in mind, and I am definitely adding it to the backlog.

[joeberetta]

thank ur for quick reply and gotcha of idea

Feel free ping me on that issue, I'll do my best to contribute on this part (not watched codebase deeply yet, but I'm familiar with nestjs, so hope I can do some contribution)

[tvanh3]

I didn’t see this answer before submitting a Feature Request, but I’ve logged it here: #294.

[joeberetta]

+1 question (or maybe even feature request)

R u planning to implement apiKey+apiSecret based auth?

Let me try to explain idea:
This option lets us use manifest as microservice (currently it looks like monolithic service with all-in-one solution)

But what if we're able to use apiKey+secret auth mechanism to communicate with api not from frontend but other backend code?

E.g. we've 2 services (orders and customers) built using manifest + 1 service (orchestrator)

Both of manifest services could make authenticate entities called "orchestrator" w/ its apiKey+secret

And orchestrator will do all the staff about users' auth and will communicate w/ microservices using w/out jwt as "user's trusted agent

[brunobuddy]

Hello @joeberetta,

Manifest already implements JSON Web Token authentication and Authorization.

This means that you other backend can log an access some restricted content (as if it was a frontend).

[joeberetta]

Correct me if I misunderstood the things

JWT based authorization requires to retrieve jwt w/ passing login+password for 1st time and only after "user" (in my case other microservice) is available for particular time to work as authorized

But in the way I've described in the requests "user" have to send apiKey and signature created from signing some particular request data (e.g. path+body) while apiSecret is stored only in private space, available for manifest backend + "user" and never shared w/ 3rd parties

Hope the explanation is bit clearer, if not let's discuss it)