Chain loading config #541
Replies: 9 comments
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Multiple options is definitely a good idea. reCaptcha is super popular, enjoys market dominance nowadays, and most users will probably want to use that. So, in regard to CAPTCHAs, supporting reCaptcha is definitely important. But, due to concerns about privacy, targeted advertising, and potential tracking and spying (regardless of whether these things actually happen, there is still a significant minority of users which distrust Google, and will have these concerns), some users might be unhappy if reCaptcha was the only option. Considering those concerns, HCaptcha could be worth investigating, too. Their motto: "Private. Secure. Faster." Claims to be built with privacy in mind, without any tracking, spying, etc. Most websites/packages/etc which I've built and maintain provide support for reCaptcha and HCaptcha. More options (e.g., Yandex, kCaptcha, etc) is even better. But of course, more options also means more work, so it also depends on how much work you want to commit to doing. ;-)
Generally speaking, INI files are okay to use. Most people will be familiar with how INI files work, they're simple, easy to use, etc. The main problems with INI files is that (1) custom data types can't be natively supported, and (2) they're limited to two-dimensional data. But, it doesn't matter much, because if really needed, you can easily fake both things by just serialising the data first, INI interprets it as a string, and when deserialised by the implementation, have the implementation perform whatever processing could be needed, or for data which is than two dimensions (matrices, complex objects, etc), use dot notation, delimit data in a similar way to CSV data, etc. Like you said, some formats will require additional libraries or extensions. That may be undesirable for some users. Of course, if a particular format is strongly desired, luckily, there are many such libraries and extensions available which could be implemented. For YAML, if we wanted something reasonably small and simple (some libraries have multiple sub-dependencies, swathes of directories, files, etc), there's a small library of classes I wrote a while back which contains a YAML handler (link here). You're welcome to use that, if you want. Doesn't need any extensions. ;-) It's what I use for configuration files, L10N files, and various other data for a number of my own projects. </Shameless Plug> 👀 But, of course, supporting everything isn't necessary. Just a few things, like a PDO connection, INI files, etc, should be perfectly okay, IMO.
I do the exact same thing for most of my packages nowadays, so.. I definitely agree with that strategy. ^^ |
Beta Was this translation helpful? Give feedback.
-
And I don't plan to write a custom handler for every possible captcha. I have developed and want to implement a mechanism in the core that allows you to use any arbitrary captcha through a callback. The callback function passed to the PHPAuth\Config should figure out the result of passing the captcha itself, possibly by getting data from the arguments (to be honest, we did not test this mechanism in detail). As a small bonus, I will give examples of a couple of options for using various captchas. $config = $config->setCaptchaValidator(static function() use ($reCaptcha_config) {
if (empty($reCaptcha_config)) {
return true;
}
if ($reCaptcha_config['recaptcha_enabled']) {
if (empty($reCaptcha_config['recaptcha_secret_key'])) {
throw new RuntimeException('No secret provided');
}
if (!is_string($reCaptcha_config['recaptcha_secret_key'])) {
throw new RuntimeException('The provided secret must be a string');
}
$recaptcha = new ReCaptcha($reCaptcha_config['recaptcha_secret_key']);
$checkout = $recaptcha->verify($captcha_response, \PHPAuth\Helpers::getIp());
if (!$checkout->isSuccess()) {
return false;
}
}
return true;
}, $reCaptcha_config); By the way, due to some technical/political limitations, reCaptcha may not be available in some countries. |
Beta Was this translation helpful? Give feedback.
-
thank you. |
Beta Was this translation helpful? Give feedback.
-
Yes, you can do that. The licensing I applied to the overall package (GNU/GPLv2) already permits copying and redistribution anyway (as long as the users of the redistributed copy can inherit the same right to copy and redistribute), so no problem. :-) (Originally chose GNU/GPLv2 in order to match with some other packages I had written previously, but have contemplated maybe switching to MIT eventually, due to MIT being a little more permissive and less verbose. Anyway, in any case, no problem). |
Beta Was this translation helpful? Give feedback.
-
My plan:
necessary and sufficient code for work:
that's all.
I think such code is much more transparent, understandable and extensible than the current architecture.
Default settings, only partially overridden by options that really need to be changed.
The default language is English, downloadable via a language pack.
A password validator, optionally included - and it can be not only
bjeavons/zxcvbn-php
, but any other validator that returns true or false.Email validator - similar.
Captcha validator - through a callback - not only google reCaptcha, but also Yandex, and kCaptcha and any other self-written one.
Similar to mail handler.
Beta Was this translation helpful? Give feedback.
All reactions