-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
feat: Update authentication middleware #6447
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Ignored Deployments
|
* initial invite token validation for authentication invocation * remove invite auth * remove unused import * cleanup tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few comments, one that I see repeating though is the usage of !
for the types, which is better to not rely on and instead do an undefined check.
auth_user?: { id: string; app_metadata: Record<string, any>; scope: string } | ||
auth?: { | ||
actor_id: string | ||
auth_user_id: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this and the actor_id point to the same ID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The auth_user_id
would be the ID of the authenticated user from the Auth module, while as the actor_id
will be the ID of the entity the authenticated user is possibly associated with.
Example: User <> Auth
auth_user_id: "authusr_1234"
actor_id: "usr_1234"
Example: Customer <> Auth
auth_user_id: "authusr_1234"
actor_id: "cus_1234"
Example: Secret API key
auth_user_id: undefined
actor_id: "sk_1234"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@olivermrbl ok understood the difference, but the naming is still confusing in my opinion. For example, tokens and users should be treated equally (they are both actors, as an actor is the one performing the operation), but an entity (eg. customer, or store) would be something completely different. Anyway it's not a blocker, but I think we need to rethink our naming and approach here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the examples above, we are treating the users and tokens equally wrt the actor. Auth user is a separate concept from entities Customer or User and is specifically designed to provide authentication to those. Do you think the auth user should be renamed? I am not sure I understand what is confusing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@olivermrbl Ok I think the part that got me confused is what customer
means, I thought it represents an organization
, but now I remembered that it's simply a storefront user
basically. All clear now 👍
packages/medusa/src/api-v2/store/customers/me/addresses/route.ts
Outdated
Show resolved
Hide resolved
packages/medusa/src/api-v2/store/customers/me/addresses/route.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes LGTM, just need tests to pass. We might need to revisit the AuthenticatedRequest
in the future, I am not sure having two types makes for a better DX. Internally yes, but not sure for external devs.
@pKorsholm, could I get you to fix the tests, so we can merge? 🙏 |
What
authenticate
andauthenticate-customer
middlewares if medusa-v2 is enabledisRegistered
check to authentication middleware to validate that a user is validated in authentication with respect to scope (default for scopes outsideadmin
andstore
is that a user is registered, requiring a manual check to validate that an id exists for the auth-user of the given scope)Why