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

Custom tool authorization for apikey, dynamically transmitted through the front-end page #1020

New Issue
Closed
opened 2026-02-21 17:29:31 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 17:29:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @weijer on GitHub (Feb 2, 2024).

Self Checks

1. Is this request related to a challenge you're experiencing?

We are a multi tenant SAAS system, and each tenant can only access their own data range. We need to dynamically include the tenant parameter in apikey.

2. Describe the feature you'd like to see

The frontend page can dynamically transmit the tool's apikey.

3. How will this feature improve your workflow or experience?

Can make it easier for our SaaS system to obtain the enterprise's own AI assistant through Dify's agent.

4. Additional context or comments

No response

5. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @weijer on GitHub (Feb 2, 2024). ### Self Checks - [X] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [X] I confirm that I am using English to file this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). ### 1. Is this request related to a challenge you're experiencing? We are a multi tenant SAAS system, and each tenant can only access their own data range. We need to dynamically include the tenant parameter in apikey. ### 2. Describe the feature you'd like to see The frontend page can dynamically transmit the tool's apikey. ### 3. How will this feature improve your workflow or experience? Can make it easier for our SaaS system to obtain the enterprise's own AI assistant through Dify's agent. ### 4. Additional context or comments _No response_ ### 5. Can you help us with this feature? - [ ] I am interested in contributing to this feature.
yindo added the 💪 enhancement label 2026-02-21 17:29:31 -05:00
yindo closed this issue 2026-02-21 17:29:31 -05:00
yindo commented 2026-02-21 17:29:31 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Feb 2, 2024):

🤖

Hey there, @weijer! Nice to see you back. Hope you're doing splendidly!

Thank you for your request. It is indeed possible to enhance the Dify platform to allow the frontend page to dynamically transmit the tool's apikey. This would involve modifying the create_api_tool_provider and update_api_tool_provider methods in the ToolManageService class to accept an additional apikey parameter. This apikey can then be included in the credentials dictionary that is passed to the ApiBasedToolProviderController.from_db method.

Here is how you can modify the create_api_tool_provider method:

@staticmethod
def create_api_tool_provider(
    user_id: str, tenant_id: str, provider_name: str, icon: dict, credentials: dict,
    schema_type: str, schema: str, privacy_policy: str, apikey: str
):
    # ... existing code ...

    # create provider entity
    provider_controller = ApiBasedToolProviderController.from_db(db_provider, auth_type, apikey)
    # load tools into provider entity
    provider_controller.load_bundled_tools(tool_bundles)

    # ... existing code ...

And here is how you can modify the update_api_tool_provider method:

@staticmethod
def update_api_tool_provider(
    user_id: str, tenant_id: str, provider_name: str, original_provider: str, icon: dict, credentials: dict, 
    schema_type: str, schema: str, privacy_policy: str, apikey: str
):
    # ... existing code ...

    # create provider entity
    provider_entity = ApiBasedToolProviderController.from_db(provider, auth_type, apikey)
    # load tools into provider entity
    provider_entity.load_bundled_tools(tool_bundles)

    # ... existing code ...

Please note that you will also need to modify the ApiBasedToolProviderController.from_db method to accept and handle the apikey parameter. You can find the relevant code in the api/services/tools_manage_service.py file.

As for how the apikey is currently being handled in the Dify platform, it is managed through the textGenerationModelList context, which is fetched using the useProviderContext() hook. This context contains a list of model providers, each with their own properties including provider_type and quota_type. You can find more details in the web/app/components/app/overview/apikey-info-panel/index.tsx file.

I hope this helps! If you have any further questions, please don't hesitate to ask.

Sources

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

@dosubot[bot] commented on GitHub (Feb 2, 2024): _🤖_ <!-- Greeting --> Hey there, @weijer! Nice to see you back. Hope you're doing splendidly! <!-- Answer --> Thank you for your request. It is indeed possible to enhance the Dify platform to allow the frontend page to dynamically transmit the tool's apikey. This would involve modifying the `create_api_tool_provider` and `update_api_tool_provider` methods in the `ToolManageService` class to accept an additional `apikey` parameter. This `apikey` can then be included in the `credentials` dictionary that is passed to the `ApiBasedToolProviderController.from_db` method. Here is how you can modify the `create_api_tool_provider` method: ```py @staticmethod def create_api_tool_provider( user_id: str, tenant_id: str, provider_name: str, icon: dict, credentials: dict, schema_type: str, schema: str, privacy_policy: str, apikey: str ): # ... existing code ... # create provider entity provider_controller = ApiBasedToolProviderController.from_db(db_provider, auth_type, apikey) # load tools into provider entity provider_controller.load_bundled_tools(tool_bundles) # ... existing code ... ``` And here is how you can modify the `update_api_tool_provider` method: ```py @staticmethod def update_api_tool_provider( user_id: str, tenant_id: str, provider_name: str, original_provider: str, icon: dict, credentials: dict, schema_type: str, schema: str, privacy_policy: str, apikey: str ): # ... existing code ... # create provider entity provider_entity = ApiBasedToolProviderController.from_db(provider, auth_type, apikey) # load tools into provider entity provider_entity.load_bundled_tools(tool_bundles) # ... existing code ... ``` Please note that you will also need to modify the `ApiBasedToolProviderController.from_db` method to accept and handle the `apikey` parameter. You can find the relevant code in the [api/services/tools_manage_service.py](https://github.com/langgenius/dify/blob/main/api/services/tools_manage_service.py) file. As for how the `apikey` is currently being handled in the Dify platform, it is managed through the `textGenerationModelList` context, which is fetched using the `useProviderContext()` hook. This context contains a list of model providers, each with their own properties including `provider_type` and `quota_type`. You can find more details in the [web/app/components/app/overview/apikey-info-panel/index.tsx](https://github.com/langgenius/dify/blob/main/web/app/components/app/overview/apikey-info-panel/index.tsx) file. I hope this helps! If you have any further questions, please don't hesitate to ask. ## Sources - [api/services/tools_manage_service.py](https://github.com/langgenius/dify/blob/main/api/services/tools_manage_service.py) - [web/app/components/app/overview/apikey-info-panel/index.tsx](https://github.com/langgenius/dify/blob/main/web/app/components/app/overview/apikey-info-panel/index.tsx) --- This response is meant to be useful and save you time. It is **not meant to be a precise solution**, but rather a starting point for your own research. Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant. If you want to continue the conversation, start your reply with @dosu-bot.
yindo commented 2026-02-21 17:29:31 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Feb 2, 2024):

API Key is designed according to your system. You can add custom rules to it in order to identify which tenant is. Or you can use another table to describe tenant-key relations.

@crazywoola commented on GitHub (Feb 2, 2024): API Key is designed according to your system. You can add custom rules to it in order to identify which tenant is. Or you can use another table to describe tenant-key relations.
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 💪 enhancement
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#1020
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?