-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed Flutterwave sdk: ENCRYPTION_KEY environment variable missing, after creating a custom environmental variable and bootstraping. #66
base: dev
Are you sure you want to change the base?
Conversation
Dependency update
Improve environment variable file detection on installation via composer
Performance Optimization and Feature Update
update: changelog and Readme
When a custom `env` variable is created, the bootstrap method was still trying to find the default env keys. With this new addition, if a user has used the `PackageConfig::setUp` method already to set their custom `env` variables, bootstrap would not have assume `self::$config` is not set again.
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
4465424 | Triggered | Generic High Entropy Secret | e8dfd50 | assets/js/v3.js | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
if you are using composer, the implementation should work just fine. use \Flutterwave\Flutterwave;
use \Flutterwave\Config\PackageConfig;
$myConfig = PackageConfig::setUp(
'FLWSECK_TEST-XXXXXXXXXXXXXXXXXXXXXXXXXXX-X',
'FLWPUBK_TEST-XXXXXXXXXXXXXXXXXXXXXXXXXXX-X',
'FLWSECK_XXXXXXXXXXXXXXX',
'staging'
);
Flutterwave::bootstrap($myConfig); Unless you are calling |
These are my environmental variables:
If you check the screenshot, immediately after here: Flutterwave::bootstrap(
PackageConfig::setUp(
$_ENV['FLUTTERWAVE_SECRET_KEY'],
$_ENV['FLUTTERWAVE_PUBLIC_KEY'],
$_ENV['FLUTTERWAVE_ENCRYPTION_KEY'],
LayConfig::$ENV_IS_DEV ? "staging" : "production",
)
); The next thing is This new call attempts to go back to the |
When a custom
env
variable is created, the bootstrap method was still trying to find the default env keys.With this new addition, if a user has used the
PackageConfig::setUp
method already to set their customenv
variables, bootstrap would not have assumeself::$config
is not set again.Version:
flutterwavedev/flutterwave-v3
:1.0.6
Error Message
This has already been done from my code.