Documentation
¶
Overview ¶
Package assetrefapi is the portal surface over the things an asset's content references (#1475): the managed resources it names, and the assets it names (#1488).
The mechanism in internal/portal/assetrefs gives an agent a way to declare a reference at save time and gives every viewing surface a way to resolve it. Neither is something a person can see or act on: before this, an owner could not tell which files their report depended on, could not add one without asking an agent to re-save, could not remove one, and could not find out what a resource was holding up before deleting it.
It serves both ends of the same edge. The asset end lists, adds and removes the references one asset declares; the target end answers "what is holding this up?" for the person about to edit or delete a file or an asset. They are one package because they are one fact read from two sides, and because the second question is the reason the first one matters: a reference carries the referencing asset's audience, so a target referenced by a publicly shared asset is readable by anyone holding that link.
It owns no policy of its own. Whether the caller may see or change an asset goes through the portal's authorization core in internal/portal/access, and whether they may reach a resource goes through resource.CanAccessResource with claims the parent builds -- the same two checks the declaration path applies to an agent (#1584).
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Register ¶
Register mounts the reference routes on mux. A deployment with no reference layer registers none of them, so the paths 404 as unknown rather than as a feature that is present and always refuses.
The two used-by routes are one handler over the two target kinds, so "what is holding this up?" cannot come to mean different things depending on what is being held.
Types ¶
type Config ¶
type Config struct {
// Refs is the reference store, the record of which asset names what.
Refs assetrefs.Store
// Resources reads the managed-resource layer. It is the declaration path's
// own view of it, so the two cannot drift onto different notions of what a
// referenceable file is. A nil reader leaves a resource reference
// unresolvable and a resource target unaddable, on a deployment that has no
// managed resources to name; asset references are unaffected.
Resources assetrefs.Resources
// Assets and Shares resolve the asset a reference hangs off -- and, for an
// asset reference, the asset it points at -- along with how widely each is
// shared. A nil Shares leaves every asset unflagged rather than unlisted:
// not knowing whether an asset is public is a smaller failure than hiding
// the fact that it references the target at all.
Assets portaldomain.AssetStore
// Blobs reads an asset's stored content, which is where a reference's URI
// is actually written. It backs the occurrence report the removal warning
// is built from; a nil reader leaves that report empty.
Blobs assetrefs.BlobReader
// Access is the portal's authorization core, built by the parent so this
// surface and the routes that stayed there answer permission questions the
// same way.
Access *access.Checker
// Claims builds a caller's managed-resource permission claims, through the
// same resource.BuildClaims every other resource surface derives them
// with. The parent supplies it because it owns the persona resolver.
Claims func(*access.User) resource.Claims
}
Config carries what the reference routes need.
Refs, Assets, Access and Claims are required; without any of them there is nothing to manage, and the routes stay unregistered rather than answering 503 to every caller. The rest are optional and each costs exactly one thing when absent: no resource references on a deployment with no managed-resource layer (asset references still work), no public-share flag on the used-by list, and no occurrence report on the reference list.
Source Files