BitPoet

Members
  • Content count

    650
  • Joined

  • Last visited

  • Days Won

    22

BitPoet last won the day on January 28

BitPoet had the most liked content!

Community Reputation

1,437 Excellent

1 Follower

About BitPoet

  • Rank
    Hero Member

Profile Information

  • Gender
    Male
  • Location
    Near Munich / Germany
  • Interests
    programming, writing, scuba diving

Recent Profile Visitors

4,208 profile views
  1. OpenSSL is just one possibility. I've also used phpseclib and am just in the process of figuring out libsodium, but all should be viable tools there. I guess standard AES256 and CBC mode should both be sufficiently secure and reasonably well documented, and openssl_random_pseudo_bytes should likely be safe enough in an up-to-date setup. Yes, you can either encrypt or search. I guess offloading en-/decryption to the database server would be possible with specialized field types, but searches would be absolute performance killers (all such fields would have to be decrypted in-memory, then flat table scans would have to be performed).
  2. @Loges: Somewhere in the middle of my (unfortunately growing) todo list is a field encryption module (or, precisely, a whole set of them for different scenarios). The bad news is that it's been there for a while and regularly been overtaken by reality (speak crypto api changes, now a badly under-documented libsodium, breached algorithms, etc.) and I've been hesitant to roll out something that might not be future-proof. You should be able to implement something quickly though if you don't aim for a generic, fool-proof-in-any-environment solution. With PW's hooks api, you could even add encryption to existing field types like FieldtypeText and its descendants. Here's a short rundown of my thoughts that might get you started with your own module: Use symmetric encryption, store your key in a property in site/config.php, make sure to avoid insecure combinations like AES256 with ECB You need at a minimum the following hooks: FieldtypeText::sleepValue where you encrypt the field values for storage in the DB. Be aware that the value passed to that might either be a string or an array of strings (in multi language sites), each of which you need to encrypt. FieldtypeText::wakeupValue where you decrypt the db values for use inside PW. You get either a string value or a LanguagesPageFieldValue object (multi language sites) for which you need to decrypt the value for every language (use getLanguageValue/setLanguageValue). FieldtypeText::getConfigInputfields to add a property (InputfieldCheckbox) that determines whether to use encryption (and is checked inside sleepValue/wakeupValue) in the field's configuration Use a truly random initialization vector (IV) for encryption, which is, depending on PHP version and configuration, sometimes harder than it sounds. Of course, back up your encryption/decryption key really good
  3. @ryan just commited my fix with a little type checking added, so the latest dev version from GitHub will behave nicely and clone _END fields to.
  4. That line number hints at PW version 2.6 or 2.7. Have you tried with a recent release? If the error still persists, it's likely a version/configuration problem on your server. PHP 7 is a bit more opinionated about the return values of session handler functions, and older versions of memcache session handlers didn't always return strings where expected. So upgrading the memcache PHP module might help, or switching to regular file sessions in php.ini would be a workaround.
  5. Keep in mind that the regular processInput method is still called afterwards, so any assignments to the page's fields will be overwritten by the submitted data. You need to fetch the $input argument from $event->arguments(0), read the submitted value from there and assign your computed value to $input["reservationdeadline"] (peek into the POST data in the developer console if you're unsure what date format to use). Don't modify $page, let the regular PW logic handle that part. Though you'd probably find it easier to remove the "required" option and run your logic in a saveReady hook.
  6. and peeked again in the github repo to find that the setLocale part was added in 2017, so 2.7.2 won't have that (yet). So, yes, my line is likely a no-op.
  7. I peeked into the setLocale method in Languages.php ($locale is fetched from the translation in wire--modules--languagesupport--languagesupport-module). } else if(strpos($locale, ';') !== false) { // multi-category and locale string, i.e. LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C foreach(explode(';', $locale) as $s) { // call setLocale() for each locale item present in the string if(strpos($s, '=') === false) continue; list($cats, $loc) = explode('=', $s); $cat = constant($cats); if($cat !== null) { $loc = $this->setLocale($cat, $loc); if($loc !== false) $setLocale .= trim($cats) . '=' . trim($loc) . ";"; } } $setLocale = rtrim($setLocale, ';'); if(empty($setLocale)) $setLocale = false; } LC_ALL=de_DE is a different case, as it contains no semicolon and is therefore passed verbatim as the value to setlocale.
  8. XXX will be treated as an invalid locale and PHP falls back to the system's default locale (which is also used when the translation is empty). My line wouldn't be ignored, but unless there are any other functions using the locale, e.g. if you use a date format with weekday or month strings somewhere, there won't be any visible differences.
  9. That de_DE could the culprit. You could try putting "LC_ALL=de_DE.utf8;LC_NUMERIC=C" (without the quotes) there instead (through the backend) to use German locale settings for everything but numeric things, for which the system's default locale will be used.
  10. There's a translated string for LanguageSupport.module named "C" that holds the locale string passed to PHP's setlocale() function.
  11. Well, since adding and deleting FieldsetOpen fields also affects the closing field, this is a little stumbling block. I've opened an issue with a suggested fix.
  12. @theo: Thank you for the feedback, and I'm glad you like my module I'm going to look into that behavior as soon as I have a little time on my hands.
  13. That's what OR-groups are for. $userTest = $users->get("(nick={$input->post->nick}), (email={$input->post->email})"); Btw., don't forget to sanitize your input before using it in selectors.
  14. I just ran simple one-liners: REM Native mkdir REM ============ REM Default PHP 7.1: php -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test1/1/2/3'; mkdir($path, 0, true);" REM 7.0: "C:\Program Files (x86)\PHP\v7.0\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test2/1/2/3'; mkdir($path, 0, true);" REM 5.3: "C:\Program Files (x86)\PHP\v5.3\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test3/1/2/3'; mkdir($path, 0, true);" REM WireFileTools REM ============= REM Default PHP 7.1: php -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test4/1/2/3'; $ft = new WireFileTools(); $ft->mkdir($path, true);" REM 7.0: "C:\Program Files (x86)\PHP\v7.0\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test5/1/2/3'; $ft = new WireFileTools(); $ft->mkdir($path, true);" REM 5.3: "C:\Program Files (x86)\PHP\v5.3\php.exe" -r "namespace ProcessWire; include('index.php'); $path = $config->paths->assets . 'test6/1/2/3'; $ft = new WireFileTools(); $ft->mkdir($path, true);"
  15. This is one of the few cases where I don't care that much since getting the new CSS selectors isn't difficult, so I just make sure to document these small UI hacks in a dedicated place in the admin area. The format and styles plugins (as well as some other basic widgets that are internally realized as plugins) are already included in the main ckeditor.js.