-
Notifications
You must be signed in to change notification settings - Fork 551
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: Machine Token Docs #1725
base: main
Are you sure you want to change the base?
feat: Machine Token Docs #1725
Conversation
Hey, here’s your docs preview: https://clerk.com/docs/pr/1725 |
f25d216
to
d6aa27f
Compare
ff5ca46
to
155ff57
Compare
155ff57
to
cfb62cb
Compare
Hey, here’s your docs preview: https://clerk.com/docs/pr/1725 |
c43da27
to
ee56c1d
Compare
docs/machine-requests/overview.mdx
Outdated
|
||
#### Examples | ||
|
||
<Tabs items={['Next.js Middleware', 'Next.js API Route']}> |
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.
feels weird to me that the authenticateRequest()
example is in a whole different tab, but it makes sense because authenticateRequest()
is it's own thing, i might be too in the weeds / looking too deep into it
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.
Yea for me I think these examples are how to use machine to machine in backend frameworks.
However, since we only have Next.js, it feels weird that these are our only examples.
running prettier removing redundant ids a "valid" id was in fact - not valid removing unneccessary "s" reverting adding pages back in different folder some minor changes machine_id has a 255 character limit Some Colin Notes
editing session requests slightly
improving authenticateRequest docs page updating auth object type editing nextjs auth docs page Removing unnecessary preface
ee56c1d
to
7e883d0
Compare
Co-authored-by: Jakob Evangelista <[email protected]>
Co-authored-by: Jakob Evangelista <[email protected]>
Co-authored-by: Bryce Kalow <[email protected]>
Co-authored-by: Bryce Kalow <[email protected]>
Co-authored-by: Bryce Kalow <[email protected]>
Co-authored-by: Bryce Kalow <[email protected]>
8ac5001
to
d029ef2
Compare
Co-authored-by: Bryce Kalow <[email protected]>
Co-authored-by: Bryce Kalow <[email protected]>
3128c79
to
0b036b1
Compare
@brkalow And @jakobevangelista I addressed all of the comments (thanks for reviewing it). Few things:
|
lgtm, prolly should ask alexis and/or nick for an extra opinions about the backend section change |
|
||
#### Examples | ||
|
||
<Tabs items={['Next.js API Route', 'Next.js Middleware']}> |
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.
Are you suggesting these two examples get used in unison? To me I feel that the best option is to have an explicit ignore in the middleware, and then do the check in the route. But this looks to suggest doing one or the other?
const { token } = await clerkClient.machineTokens.create({ | ||
machineId: 'mch_cron', | ||
claims: { | ||
permissions: ['read', 'write'], |
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.
Some explanation around what the purpose of this is would be good, my guess is for the route to check that not only is the POST request authenticated but that its also authorized? I feel it would be beneficial to have down in the example below pulling these claims out and checking against them.
|
||
Every machine token you create needs to be associated with a `machine_id`. You can pick any value for the `machine_id` as long as it meets the following requirements: | ||
|
||
- It must be prefixed with `mch_` |
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.
Since I am already explicitly calling clerkClient.machineTokens.create
couldn't the sdk just prefix the id with mch_
for me? If it has to be this way then I think this is pretty clearly outlined. The types for this field should definitely be `mch_${string}`
to enforce this.
- ❌ `MCH_UPPERCASE` | ||
|
||
### Claims | ||
|
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.
An example here of how this works would be helpful, even better if the example showed how to type the claims, or validate them with a schema.
|
||
### Machine ID | ||
|
||
Every machine token you create needs to be associated with a `machine_id`. You can pick any value for the `machine_id` as long as it meets the following requirements: |
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.
It's not necessarily clear why a machine_id is required. Is it purely an internal thing for clerk? Does this give us controls in clerk dashboard to "ban" a machine? Are we supposed to validate the machine_id where we are receiving the request?
Clerk redirects PR: https://github.com/clerk/clerk/pull/964
Currently all customer-facing tokens are session tokens. We are adding
machine tokens
which is another customer-facing token. This PR adds documentation on:Additionally because now, all backend requests may no longer have a user + session associated with them, I modified the structure of some of the docs pages, and slightly edited existing pages to help fit the concept of "machine authentication". Read below to see what I changed.
Created the following machine request pages:
/docs/machine-requests/overview
/docs/machine-requests/machine-tokens
/docs/machine-requests/manual-jwt
Moved most of the "Backend Requests" pages to "Session Requests"
Calling this section "backend request" is confusing because machine requests are also backend requests.
This caused most of the "files changed" in the PR because a lot of links were changed from @NWylynko's script.
Some pages that were in "Backend Requests" didn't fit under "Session Requests," so they were moved to their own section:
Modified the following pages to add the concept of machine authentication:
Slack thread:
https://clerkinc.slack.com/archives/C01QFRQNHSN/p1738141182851989
Checklist