langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-08-27 21:10:04 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

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

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/32323

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()

Code Changes

# After session.commit() in AppCopyApi.post():

# Inherit web app permission from original app
if result.app_id and FeatureService.get_system_features().webapp_auth.enabled:
    try:
        # Get the original app's access mode
        original_settings = EnterpriseService.WebAppAuth.get_app_access_mode_by_id(app_model.id)
        access_mode = original_settings.access_mode
    except Exception:
        # If original app has no settings (old app), default to public to match fallback behavior
        access_mode = "public"
    
    # Apply the same access mode to the copied app
    EnterpriseService.WebAppAuth.update_app_access_mode(result.app_id, 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 a sso_verified app → copy requires SSO
  • ✅ 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 (inconsistent with original)
  • 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 - Enterprise PR that changes fallback default from public to private
  • This fix ensures copied apps get explicit permissions, preventing reliance on fallback behavior

Files Changed

  • api/controllers/console/app/app.py (+13 lines)
**Original Pull Request:** https://github.com/langgenius/dify/pull/32323 **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()` ## Code Changes ```python # After session.commit() in AppCopyApi.post(): # Inherit web app permission from original app if result.app_id and FeatureService.get_system_features().webapp_auth.enabled: try: # Get the original app's access mode original_settings = EnterpriseService.WebAppAuth.get_app_access_mode_by_id(app_model.id) access_mode = original_settings.access_mode except Exception: # If original app has no settings (old app), default to public to match fallback behavior access_mode = "public" # Apply the same access mode to the copied app EnterpriseService.WebAppAuth.update_app_access_mode(result.app_id, 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 a sso_verified app → copy requires SSO - ✅ 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 (inconsistent with original) - **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 - Enterprise PR that changes fallback default from public to private - This fix ensures copied apps get explicit permissions, preventing reliance on fallback behavior ## 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#33669
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?