8000 Scope and access discussion · Issue #581 · projectawakening/world-chain-contracts · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Scope and access discussion #581

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.

Sign up for GitHub

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

Jump to bottom
Open
dk1a opened this issue May 21, 2025 · 0 comments
Open

Scope and access discussion #581

dk1a opened this issue May 21, 2025 · 0 comments

Comments

@dk1a
Copy link
Contributor
dk1a commented May 21, 2025 •
edited
Loading

@ccp-tezza I'm moving here from #578 to make this discussion less hidden

I think I'll have better ideas in a few weeks, I've only started experimenting with SOF last week. So far I feel like we have some different ideas for how to use it, but that may stem from my lack of understanding, as well as different use-cases, as well as incompleteness of SOF since v2 is a work in progress

Currently I'm trying to see if I want to ditch access and use:

  • libraries for custom access control of entrypoint systems, some can probably remain System since no scoping is relevant (e.g. NFT ownership determines who can call the actions of relevant character)
  • 1-2 default entity guards that check for scope and direct access in one go (e.g. definition and usage)

Some questions:

  • access as it is introduces a lot of complicated configuration via scripts, what is the benefit over just calling an access check? From what I can see, these checks are one-offs, not entity-by-entity configurations implemented by individual entity owners
  • why does EntitySystem accept classId in registerClass, and objectId in instantiate? I assume it's so the offchain server can be the source of truth for those ids. Would letting EntitySystem control all entity creation be better, if the server could receive those entities from system calls?
  • why do you use smartObjectId instead of just entityId? Also what is tenantId?
  • CallAccess uses addresses granted via scripts, which then become stale on system updates (and old systems can then be maliciously re-registered, though it's hard/unlikely to really exploit). Have you considered using systemIds instead? Or perhaps indirect access of sorts, as opposed to only direct access (I mean allowing some role members call some funcs without callCount == 1)?
  • thoughts on scoping systems for objects, not just classes? And addToScope which could be relevant for both?
  • do you have a specific exploit example that _contextGuard prevents? I'd assume namespace access control would prevent any attempts at malicious delegatecalling, but I might be missing something
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@dk1a
0