update can repoint a satellite's main node without re-checking the target
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- csharp
- Domain
- authorization, backend
Research direction
The issue describes authorization for satellite updates and references the create path fixed in #7601, but names no files or tests. Read the update and create authorization paths and inspect the linked triage node to locate the relevant code. Done means updates apply the same ownership treatment as creates and the new MainNode target is checked; the issue requires post-roll verification to close.
Written by the indexing model from the issue text.
Description
A satellite node (comment, thread, activity, ...) delegates its access decisions to its MainNode. An update routed to the satellite's owning hub is authorised against the STORED node, and the satellite access rule never checked the proposed MainNode. An update could therefore change which main node governs a satellite without the new target being checked.
A create already derives ownership from the path or the stored node and ignores a caller-supplied MainNode (#7601). The update path needs the same treatment.
Found while reviewing #7601. Triage node: rbuergi/Feedback/fb-592206cd0b55eebbd6f27145a04e5bf1 (memex.systemorph.com).
A fix is in progress in the linked pull request. This issue closes only after post-roll verification (policy severity-closes-on-verification).
- Dominant language
- C#
- Stars
- 12
- Forks
- 5
- Avg merge
- 5h 37m
- Merged PRs (30d)
- 959
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Systemorph/MeshWeaver
-
bug ci-template-feed sev:M
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Systemorph/MeshWeaver#7660 ·
Maintainers usually reply within 1 day
-
chore ci-artifact-store-miss sev:M
Difficulty 4/5 3-5 days Newbie friendliness 44/100
Systemorph/MeshWeaver#7656 ·
Maintainers usually reply within 1 day
-
GitSync: an Ignore pattern added after the first import leaves the imported nodes in place, and on a one-way Space nobody can remove themPossibly taken @rbuergi claimed this today. Openenhancement feature:gitsync-ownership feature:node-delete sev:M
Difficulty 5/5 Over a week Newbie friendliness 35/100
Systemorph/MeshWeaver#7611 ·
Maintainers usually reply within 1 day
-
bug sev:B
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Systemorph/MeshWeaver#7598 ·
Maintainers usually reply within 1 day
-
Mesh teardown leaves mail module generations loaded — one lease still held on Mail.MicrosoftGraph and Mail.GmailPossibly taken @rbuergi claimed this today. Openbug sev:L
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Systemorph/MeshWeaver#7577 · 2 comments ·
Maintainers usually reply within 1 day
All issues in Systemorph/MeshWeaver
Similar issues
-
possible bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Include host.wslc.internal in the HTTPS development certificatePossibly taken @afscrome claimed this today. Openarea-commandlinetools
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
dotnet/aspnetcore#70122 · 1 comment ·
Maintainers usually reply within 1 day
-
:1st_place_medal: good first issue :cowboy_hat_face: refactor :roller_coaster: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ApplETS/Backend-Hello#78 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 2 days
-
status/triage
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Altinn/altinn-studio#21642 ·
Maintainers usually reply within 1 day