langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-22 20:45:26 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #32322] fix(app-copy): inherit web app permission from original app #33670

New Issue
Closed
opened 2026-02-21 20:53:41 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:53:41 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/32322

State: closed
Merged: Yes

Summary

When copying an app, the copied app was not getting a web_app_settings record created. This caused the enterprise service to query for settings that don't exist, falling back to default behavior which could expose copied apps unintentionally.

Changes

This fix ensures copied apps inherit the same access mode as the original app:

  • If original has explicit settings (public/private/private_all/sso_verified) → copy gets the same setting
  • If original has no settings (old apps) → copy defaults to "public" to match the original's effective permission via fallback

Implementation

Added permission inheritance logic in AppCopyApi.post() (api/controllers/console/app/app.py):

  1. After app import completes, check if webapp_auth feature is enabled
  2. Try to get the original app's access mode from enterprise service
  3. If original has settings, inherit the same access mode
  4. If original has no settings (exception), default to "public" to preserve effective behavior
  5. Apply the access mode to the copied app via EnterpriseService.WebAppAuth.update_app_access_mode()

Testing

Manual testing should verify:

  • ✅ Copying a public app → copy is public
  • ✅ Copying a private app → copy is private
  • ✅ Copying a private_all app → copy is private_all
  • ✅ Copying an old app (no web_app_settings) → copy gets "public" (matches original effective permission)

Impact

  • Before: Copied apps had no permission record → fell back to default behavior
  • After: Copied apps get explicit permission record matching original app
  • Backward Compatibility: Old apps without settings get "public" default (preserves current effective behavior)

Related

Files Changed

  • api/controllers/console/app/app.py (+13 lines)
**Original Pull Request:** https://github.com/langgenius/dify/pull/32322 **State:** closed **Merged:** Yes --- ## Summary When copying an app, the copied app was not getting a `web_app_settings` record created. This caused the enterprise service to query for settings that don't exist, falling back to default behavior which could expose copied apps unintentionally. ## Changes This fix ensures copied apps inherit the same access mode as the original app: - **If original has explicit settings** (public/private/private_all/sso_verified) → copy gets the same setting - **If original has no settings** (old apps) → copy defaults to "public" to match the original's effective permission via fallback ## Implementation Added permission inheritance logic in `AppCopyApi.post()` (api/controllers/console/app/app.py): 1. After app import completes, check if webapp_auth feature is enabled 2. Try to get the original app's access mode from enterprise service 3. If original has settings, inherit the same access mode 4. If original has no settings (exception), default to "public" to preserve effective behavior 5. Apply the access mode to the copied app via `EnterpriseService.WebAppAuth.update_app_access_mode()` ## Testing Manual testing should verify: - ✅ Copying a public app → copy is public - ✅ Copying a private app → copy is private - ✅ Copying a private_all app → copy is private_all - ✅ Copying an old app (no web_app_settings) → copy gets "public" (matches original effective permission) ## Impact - **Before:** Copied apps had no permission record → fell back to default behavior - **After:** Copied apps get explicit permission record matching original app - **Backward Compatibility:** Old apps without settings get "public" default (preserves current effective behavior) ## Related - langgenius/dify-enterprise#423 - Cherry-picked from commit c15d956fe5 (fix branch for main) ## Files Changed - `api/controllers/console/app/app.py` (+13 lines)
yindo added the pull-request label 2026-02-21 20:53:41 -05:00
yindo closed this issue 2026-02-21 20:53:41 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#33670
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?