mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
snowflake_sql plugin OAuth client Id corruption #883
Reference in New Issue
Block a user
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?
Originally created by @HABE-WAKAM on GitHub (Dec 18, 2025).
Self Checks
Dify version
1.10.1
Plugin version
0.0.1
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
Follow the configuration steps on the README page, creating the security Integration on snowflake and using the right parameters on the snowflake_sql plugin.
✔️ Error log
I have this error when trying to start the integration.
OAuth client integration with the given client id is not found.
When investigating the issue I noticed that the client_id used in the URI is not the same that is configured. That's why snowflake does not recognise it.
@dosubot[bot] commented on GitHub (Dec 18, 2025):
The snowflake_sql plugin uses the OAuth client_id exactly as configured in its settings—there’s no mutation or overwriting in the plugin code. If the client_id in the OAuth URI doesn’t match what you configured, it’s almost always due to a misconfiguration in the Dify backend or a mismatch between what’s registered in Snowflake and what Dify is actually using.
Here’s a checklist to resolve this:
.envor Docker Compose file, and restart all containers after making changes. This variable is used to build the redirect URI and impacts OAuth flows for all plugins (example).If you follow these steps and ensure all values match exactly, the OAuth integration should work as expected. If you’re still seeing mismatches, let me know what values you see in the database and your environment, and I can help you dig deeper.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@HABE-WAKAM commented on GitHub (Dec 19, 2025):
@dosu I checked in the table Tool_OAuth_Tenant_Client and I saw that the client_id and client_secret values are like encoded in a way and are not equal to the values I configured. Is there any sort of hashing or encoding that is applied when inserting values in that table ?
@dosubot[bot] commented on GitHub (Dec 19, 2025):
Yes, the client_id and client_secret values in the Tool_OAuth_Tenant_Client table are encrypted before being stored, not just encoded or hashed. Dify uses AES-CBC encryption with a key derived from the application's SECRET_KEY, and the encrypted data is base64-encoded—so the values in the table will look very different from what you entered. This encryption is reversible and handled automatically by Dify, so the original values are restored when needed for OAuth operations. This is a security feature and expected behavior, not a bug or misconfiguration. As long as you entered the correct credentials, Dify will use them correctly during OAuth flows. You can see the encryption logic in the code here: provider_encryption.py and system_oauth_encryption.py.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@HABE-WAKAM commented on GitHub (Dec 19, 2025):
@dosu when the authentication popup appears, I see that it is using the encrypted values in the URI and not the decrypted ones. Is this normal ?
@dosubot[bot] commented on GitHub (Dec 19, 2025):
No, it's not normal for the authentication popup to use encrypted values in the OAuth URI—those values should be decrypted (plaintext) before being sent. Dify encrypts sensitive credentials like client_id and client_secret in the database for security, but always decrypts them before using them in OAuth flows. If you see encrypted (base64-like) values in the URI, it usually means the decryption step failed or the wrong value is being read, which could be due to an incorrect SECRET_KEY, cache issues, or a misconfiguration in the plugin or tenant setup.
Check that your SECRET_KEY is consistent across all services, restart your containers, and make sure the correct tenant and plugin configuration is being used. Also, look for any error logs related to decryption failures during the OAuth flow—those can help pinpoint the issue. If you can share any relevant logs or config details, I can help you dig deeper.
For more on how Dify handles this, see the code for decryption and OAuth flow:
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@HABE-WAKAM commented on GitHub (Dec 19, 2025):
@dosu can you give me steps to check the possible issues ?
@dosubot[bot] commented on GitHub (Dec 19, 2025):
Here’s a step-by-step checklist to help you diagnose why encrypted values are appearing in the OAuth URI for the Snowflake plugin:
SECRET_KEY Consistency: Make sure the SECRET_KEY environment variable is set to the exact same value across all Dify services and containers. If the key is different anywhere, decryption will fail and you’ll see encrypted values in the OAuth URI instead of the real client_id and client_secret. Restart all containers after confirming this.
Plugin/Tenant Configuration: Double-check that the Snowflake plugin is using the correct tenant and plugin configuration. Sometimes, the backend may use a default/system client if the tenant-specific one isn’t enabled or set up correctly.
Database Values: In the Tool_OAuth_Tenant_Client table, the client_id and client_secret are stored encrypted (base64-encoded AES-CBC). This is normal, but when Dify fetches them for OAuth, it should decrypt them before use. If you see encrypted values in the OAuth URI, it means the decryption step failed upstream (not in the plugin itself) reference.
Restart After Changes: If you change any environment variables (especially SECRET_KEY or CONSOLE_API_URL), or update plugin credentials, you must restart all Dify containers to ensure the new values are loaded everywhere.
Check Error Logs: Look for error logs in your Dify backend during the OAuth flow. Specifically, search for decryption errors or exceptions related to the SystemOAuthEncrypter or get_oauth_client. These will help pinpoint if the SECRET_KEY is wrong or if there’s a problem with the encrypted data reference.
Redirect URI Match: Ensure the redirect URI registered in Snowflake matches exactly what Dify constructs (protocol, domain, port, and path). Even a small mismatch will cause OAuth failures, but this won’t cause encrypted values in the URI—it’s just another common source of OAuth errors reference.
Cache/Credential Refresh: If you recently updated credentials or configuration, clear any relevant caches and restart services to force Dify to reload the latest values.
If you follow these steps and still see encrypted values in the OAuth URI, focus on SECRET_KEY mismatches and check for decryption errors in your logs. The plugin itself always expects decrypted values—if it gets encrypted ones, the problem is upstream in the backend or environment.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@HABE-WAKAM commented on GitHub (Dec 19, 2025):
@dosu can you explain how the client_id is being used in the code, at which moment in the code is it decoded when executing the OAuth flow ?
@dosubot[bot] commented on GitHub (Dec 19, 2025):
Here’s how it works in the code:
The client_id is stored encrypted in the ToolOAuthTenantClient table. When the OAuth flow starts, the Dify backend (specifically, the get_oauth_client method in BuiltinToolManageService) fetches this record and decrypts the oauth_params—including client_id—using a provider-specific encrypter (SystemOAuthEncrypter, which uses your SECRET_KEY) before returning them for use in the OAuth process. This decryption happens before any plugin code runs, so the plugin only ever receives the plaintext client_id in the system_credentials dictionary. The snowflake_sql plugin then uses this decrypted client_id directly to build the OAuth authorization URL and for token exchange—there’s no decryption logic in the plugin itself.
If you see encrypted values in the OAuth URI, it means the decryption step failed upstream (usually due to a SECRET_KEY mismatch or misconfiguration), not in the plugin code itself.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@HABE-WAKAM commented on GitHub (Dec 19, 2025):
@dosu in which containers should the SECRET_KEY variable should be set ?
@dosubot[bot] commented on GitHub (Dec 19, 2025):
SECRET_KEY must be set in all containers that handle backend logic for Dify, specifically: api (backend), worker (Celery worker), worker_beat (Celery beat), and plugin_daemon. These containers use SECRET_KEY to encrypt and decrypt sensitive data like OAuth credentials. Make sure the value is identical in each container’s environment (usually via your .env file and Docker Compose), and restart all containers after any change. If SECRET_KEY is missing or mismatched, decryption will fail and you’ll see issues like encrypted values leaking into OAuth URIs, causing authentication errors. Frontend/web containers do not require SECRET_KEY for this purpose.
Reference: docker-compose.yaml | Reference: .env.example
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@HABE-WAKAM commented on GitHub (Dec 19, 2025):
@dosu where should I configure this SECRET_KEY variable knowing that I use kubernetes to deploy dify
@dosubot[bot] commented on GitHub (Dec 19, 2025):
You should store SECRET_KEY as a Kubernetes Secret and inject it into all Dify backend pods that handle encryption/decryption (api, worker, worker_beat, plugin_daemon). Here’s a typical approach:
(You can generate the value with:
echo -n 'your-secret-key' | base64)Make sure this is present in the env section for api, worker, worker_beat, and plugin_daemon pods. The frontend/web pods do not need SECRET_KEY for this purpose.
SECRET_KEY must be identical across all backend pods and should never change if you have existing encrypted data, or you’ll lose access to that data. If you’re using a community Helm chart or YAML, check that it supports injecting custom secrets—otherwise, you may need to adapt it.
Let me know if you want a full example for Helm, Kustomize, or plain YAML, or if you have questions about secret management in Kubernetes.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other