跳到主要内容
ArcBlock Community

Limitations of Blocklet-issued admin key vs Blocklet Server Issued admin key.

Twelve
开发者
blocklet-serverbug

Hello team,

We built a DeBOS onboarding flow in the app that lets an admin create a passport invite, assign a role and capabilities, and optionally create the employee record after acceptance. The Blocklet dashboard can send invites directly, but our DeBOS UI cannot use the invite flow unless it has a key from Blocklet Server. Shouldn’t the Blocklet-issued admin key be enough for this too? Right now that means Blocklet users lose some autonomy, because they have to get a server key from us instead of just being able to use the keys available to them in their blocklet.

Having to share a key from our Blocklet server with with blocklets hosted on it would also seem to carry some risks. We cannot just hand off these keys to clients, and even if we gate them in the .env im worried that there could be leakage.

5 条回复

wangshijun3个月前

Seems invitation management is not supported by @blocklet/sdk now, but supporting this should not be hard, will release a beta soon.

👍1
Twelve3个月前

That sounds good to me.

wangshijun3个月前

You can have a try on @blocklet/sdk@1.17.13-beta-20260613-094425-b81920c8

Twelve3个月前

Thank you. Works perfect! This is a much more secure flow for my application.

Twelve3个月前

Quick update here: I said this was working, but at that point I had only proven it on our dev instance. We hit more issues on the live mounted instance and finally tracked down the full flow.

What we built:

DeBOS has an Employee Onboarding UI that creates or reuses a Passport role, creates a Blocklet member invitation, stores the invite in our app, and shows the invitation link to the admin so they can send it to the employee.

What finally worked:

For browser-created invitations, both role creation and member invitation creation need to use the current owner/admin browser session, not a signed access key path. In our case the working flow is:

  • DeBOS owner/admin clicks Create Invite
  • backend preserves the incoming login_token cookie and forwarded host/protocol
  • backend calls Blocklet Server GraphQL at the root service endpoint:https://<host>/.well-known/service/api/gql
  • same session creates/reuses the Passport role
  • same session creates the member invitation

One important mounted-app issue:

Our live app is mounted at:

https://debos.12inchapps.com/_debos/

So PUBLIC_APP_URL is correctly set to that mounted URL for normal app links.

But the actual invitation acceptance link must NOT include the app mount path. This is the working invite URL shape:

https://debos.12inchapps.com/.well-known/service/invite?inviteId=&lt;id>

This broken shape loads the app shell instead of the invite page:

https://debos.12inchapps.com/_debos/.well-known/service/invite?inviteId=&lt;id>

Some errors we saw while sorting this out:

  • No valid passport found: you don't have the required role "sdk"
  • not allowed Check PASSPORT_TEAM_DID/BLOCKLET_APP_PID and x-access-blocklet context
  • verify failed keyId: ...
  • invite was created, but the returned/displayed URL pointed under the mounted app path

So the two big takeaways for SDK / docs might be:

  1. Browser-session-authenticated invitation management should be supported directly, because a blocklet UI may need to let an owner/admin manage invitations without creating server-level access keys.
  2. Mounted apps need special handling: app URLs may include the mount path, but Blocklet service URLs like GraphQL and invite acceptance should resolve at the host root service namespace.

Hope that helps with the beta invitation management work. This took us a while to isolate, so I wanted to share the exact distinction.

回复