starred/panel-pelican-dev
1
0
Fork 0
mirror of https://github.com/pelican-dev/panel.git synced 2026-07-16 04:03:50 +03:00
Code Issues 41 Packages Projects Releases 10 Wiki Activity

[PR #2002] [CLOSED] Fix role-based server access for users with node-restricted permissions #1698

New Issue
Closed
opened 2026-02-05 18:21:54 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-05 18:21:54 +03:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/pelican-dev/panel/pull/2002
Author: @memesalot
Created: 12/14/2025
Status: ❌ Closed

Base: main ← Head: main

📝 Commits (3)

  • 32cc844 Refactor Node and User models for role management and permission checks
  • d844673 Update Node model to use NodeRole for role relationships
  • 028dba0 fix oops

📊 Changes

3 files changed (+44 additions, -11 deletions)

View changed files

📝 app/Models/Node.php (+2 -3)
📝 app/Models/User.php (+27 -3)
📝 app/Policies/ServerPolicy.php (+15 -5)

📄 Description

Description

Fixes a bug where users assigned to roles with server permissions and node restrictions could not see or access servers on their assigned nodes. Users could only see servers they directly owned, even when their role granted them broader access.

Changes

app/Models/Node.php

  • Changed the roles() relationship from HasManyThrough to BelongsToMany to correctly handle the many-to-many relationship through the node_role pivot table.

app/Models/User.php

  • Added canViewServers() method that directly checks for the viewList server permission using Spatie's hasPermissionTo(), bypassing the fragile policy chain.
  • Updated accessibleServers() to use the new canViewServers() method instead of canned('viewAny', Server::class).
  • Updated canAccessTenant() to check for role-based access when the user is not an owner or subuser.

app/Policies/ServerPolicy.php

  • Modified before() to directly check role-based permissions using hasPermissionTo() after verifying the user can target the server's node.

Root Cause

The Node::roles() relationship was incorrectly defined as HasManyThrough instead of BelongsToMany, causing accessibleNodes() queries to return incorrect results. Additionally, permission checks were relying on a complex policy chain that wasn't properly triggering Spatie's permission verification.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/pelican-dev/panel/pull/2002 **Author:** [@memesalot](https://github.com/memesalot) **Created:** 12/14/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `main` --- ### 📝 Commits (3) - [`32cc844`](https://github.com/pelican-dev/panel/commit/32cc8443063a86fa52bbf1f989f94767afad01f6) Refactor Node and User models for role management and permission checks - [`d844673`](https://github.com/pelican-dev/panel/commit/d8446736e750e51974dda6c04082a65cd044c21d) Update Node model to use NodeRole for role relationships - [`028dba0`](https://github.com/pelican-dev/panel/commit/028dba0ab39b24e21abcb63e2820f7671bac5b57) fix oops ### 📊 Changes **3 files changed** (+44 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `app/Models/Node.php` (+2 -3) 📝 `app/Models/User.php` (+27 -3) 📝 `app/Policies/ServerPolicy.php` (+15 -5) </details> ### 📄 Description ## Description Fixes a bug where users assigned to roles with server permissions and node restrictions could not see or access servers on their assigned nodes. Users could only see servers they directly owned, even when their role granted them broader access. ## Changes ### `app/Models/Node.php` - Changed the `roles()` relationship from `HasManyThrough` to `BelongsToMany` to correctly handle the many-to-many relationship through the `node_role` pivot table. ### `app/Models/User.php` - Added `canViewServers()` method that directly checks for the `viewList server` permission using Spatie's `hasPermissionTo()`, bypassing the fragile policy chain. - Updated `accessibleServers()` to use the new `canViewServers()` method instead of `canned('viewAny', Server::class)`. - Updated `canAccessTenant()` to check for role-based access when the user is not an owner or subuser. ### `app/Policies/ServerPolicy.php` - Modified `before()` to directly check role-based permissions using `hasPermissionTo()` after verifying the user can target the server's node. ## Root Cause The `Node::roles()` relationship was incorrectly defined as `HasManyThrough` instead of `BelongsToMany`, causing `accessibleNodes()` queries to return incorrect results. Additionally, permission checks were relying on a complex policy chain that wasn't properly triggering Spatie's permission verification. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
OVERLORD added the pull-request label 2026-02-05 18:21:54 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
not confirmed
pull-request
Mirrored from GitHub Pull Request
 👑 sponsor
💰 fund
🔴 hard
🟡 medium
🟡 medium
🟡 medium
🟢 easy
🟢 easy
🟢 easy
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/panel-pelican-dev#1698
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?