Skip to content
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

Merged
merged 26 commits into from
Feb 27, 2024

Conversation

pKorsholm
Copy link
Contributor

@pKorsholm pKorsholm commented Feb 20, 2024

What

  • disabled authenticate and authenticate-customer middlewares if medusa-v2 is enabled
  • add isRegistered check to authentication middleware to validate that a user is validated in authentication with respect to scope (default for scopes outside admin and store is that a user is registered, requiring a manual check to validate that an id exists for the auth-user of the given scope)
  • add authentication middlewares for the remaining api-v2 endpoints

Why

  • disable: because passport middlewares were interfering with api-v2 and we are moving away from passport
  • validating a user/customer is registered and not just that the auth-user exists is important to know they have a profile

@pKorsholm pKorsholm requested review from a team as code owners February 20, 2024 09:47
Copy link

changeset-bot bot commented Feb 20, 2024

⚠️ No Changeset found

Latest commit: 4c8afe4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

vercel bot commented Feb 20, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
medusa-dashboard ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 27, 2024 5:15am
3 Ignored Deployments
Name Status Preview Comments Updated (UTC)
api-reference ⬜️ Ignored (Inspect) Feb 27, 2024 5:15am
docs-ui ⬜️ Ignored (Inspect) Visit Preview Feb 27, 2024 5:15am
medusa-docs ⬜️ Ignored (Inspect) Visit Preview Feb 27, 2024 5:15am

* initial invite token validation for authentication invocation

* remove invite auth

* remove unused import

* cleanup tests
@olivermrbl olivermrbl changed the title Feat/update authentication middleware feat: Update authentication middleware Feb 22, 2024
Copy link
Member

@sradevski sradevski left a 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.

packages/medusa/src/utils/authenticate-middleware.ts Outdated Show resolved Hide resolved
packages/medusa/src/utils/authenticate-middleware.ts Outdated Show resolved Hide resolved
auth_user?: { id: string; app_metadata: Record<string, any>; scope: string }
auth?: {
actor_id: string
auth_user_id: string
Copy link
Member

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?

Copy link
Contributor

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"

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member

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/route.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@olivermrbl olivermrbl left a 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.

@olivermrbl
Copy link
Contributor

@pKorsholm, could I get you to fix the tests, so we can merge? 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants