Leaderboard

I solved it myself by the following code. 1. Create a custom RepeaterPage class for my tracks and add a specific method to create a session-based URL for streaming. <?php namespace ProcessWire; /** * @property Pagefile $audio */ class TracksRepeaterPage extends RepeaterPage { /** * @param string $streamUrl Default stream URL when audio file does not exist * * @return string */ public function getStreamUrl(string $streamUrl = ''): string { // Check whether audio file exists and if it does create a session-based stream URL if ($this->audio) { // Create the file hash and add it to the session as key for the audio file path $audioPath = $this->audio->filename(); $fileHash = hash('sha1', $audioPath . session_id()); session()->setFor('stream', $fileHash, $audioPath); // Create the stream URL with the file hash $streamUrl = '/stream/' . $fileHash . '.mp3'; } return $streamUrl; } } 2. Create a custom hook to watch for the stream URL in the ready.php: <?php namespace ProcessWire; if (!defined("PROCESSWIRE")) { die(); } wire()->addHook('/stream/([\w\d]+).mp3', function ($event) { // Get the audio file path by file hash $fileHash = $event->arguments(1); $audioPath = session()->getFor('stream', $fileHash); // Check whether audio file exists and stream it when it does or throw 404 if (file_exists($audioPath)) { wireSendFile($audioPath, [], [ 'content-transfer-encoding' => 'chunked', 'accept-ranges' => 'bytes', 'cache-control' => 'no-cache' ]); } throw new Wire404Exception(); }); Ta da! 🙂 When the session expires, the session-based file hashes are destroyed and the stream URL no longer work. So every time the session is renewed with a new session ID, a new unique session-based stream URL is generated for each tracks. Have I missed anything or are there any security issues?

UPDATE 2: I was able to get the bootstrap migration to install without problems, after deleting the assets/cache/dbmigrations folder (I didn't know about that before) and also using version 2.0.23 of the module.

Hey @FireWire this issue should be fixed in v5.9.2 🙂 Please mark the topic [solved] if it works for you! Thx

We’re moving along with trying to cover as many small issue fixes as possible for the next main/master version. So that’s what all the commits this week are for. There’s not much more to report than that, making good progress! If you spot any new issues on the dev branch be sure to report them in the processwire-issues repository. Thanks and have a great weekend!

You can create a custom PHP Configuration: https://ddev.readthedocs.io/en/stable/users/extend/customization-extendibility/#custom-php-configuration-phpini You can test something like this: File - .ddev/php/my-php.ini [PHP] display_errors = On; error_reporting = E_ALL;

Hello Everyone, For our KIT325 Cybersecurity Project, we recently checked the security of ProcessWire CMS, a system used for managing website content. We wanted to see if its default settings are secure enough based on the OWASP Top 10 standards, which are common web security guidelines. Here’s a quick look at what we found and what could be improved: Blocking Brute Force Login Attempts: What We Found: ProcessWire does slow down login attempts if someone keeps trying the wrong password. But it only blocks based on username, not by tracking where the login attempts come from (like IP addresses). Suggestion: It would be safer if ProcessWire blocked login attempts based on IP as well. Also, the system could use a response code like “429 Too Many Requests” to alert attackers that they’re being blocked. Session Cookie Security: What We Tried: Session cookies (used to keep users logged in) seem secure, but we couldn’t fully test if they were safe from all advanced attacks. Future Testing: We’d need more tools and knowledge to explore if these session cookies could ever be forged to trick the system. File Access Control: What We Saw: Files from unpublished pages could still be accessed if someone knew the file path, which could leak private information. Fix: ProcessWire should make a certain setting ($config->pagefileSecure) enabled by default to restrict file access based on page permissions. This way, only authorized users can see those files. HTTPS (Secure Connection) Enforcement: Current Setup: ProcessWire requires HTTPS (secure connection) settings to be turned on manually in the .htaccess file, which may not be done by every user. Recommendation: It would be better if HTTPS were enabled by default, so all sites are secure right from the start. Improving Activity Logs: Missing Logs: Some important activities like content changes and role updates aren’t logged by default. Suggestion: ProcessWire should add logs for these actions. This way, any unusual activity can be tracked and traced back to the user who made the changes. Password Rules: Issue: Passwords set through the API (another way to interact with the system) might not meet the same security rules as those set in the admin panel. Improvement: ProcessWire should require all passwords to meet the same standard, ideally making them at least 12 characters long and easier for users to remember. Overall, ProcessWire has a strong security foundation, but these adjustments could make it even safer. This experience showed us the value of secure default settings, especially for users who might not make these changes on their own.

UPDATE 2022 Simple and powerful - put this at the end of your config.php file: $localConfig = __DIR__ . "/config-local.php"; if (is_file($localConfig)) include $localConfig; Then put all local settings into config-local.php (same concept for DEV/STAGING/PRODUCTION): <?php namespace ProcessWire; /** @var Config $config */ $config->debug = true; $config->advanced = true; $config->dbName = 'db'; $config->dbUser = 'db'; $config->dbPass = 'db'; $config->dbHost = 'db'; $config->userAuthSalt = '1234'; $config->tableSalt = '1234'; $config->httpHosts = ['xyz.ddev.site']; // this prevents logout when switching between // desktop and mobile in chrome devtools $config->sessionFingerprint = false; // RockFrontend $config->livereload = 1; // RockMigrations // $config->filesOnDemand = 'https://your-live.site/'; $config->rockmigrations = [ 'syncSnippets' => true, ]; // tracy config for ddev development $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => '/Users/xyz/code/yourproject/', 'numLogEntries' => 100, // for RockMigrations ]; $config->rockpagebuilder = [ "createView" => "latte", ]; -------------------- OLD POST from 2018: Have you ever come across the situation where you needed to change your config.php file for local development? Have you ever come across this warning? Say goodbye to this little annoying tasks Some of you might know that you can have a separate config-dev.php file for local development. This is nice, but also needs some setup (for example excluding this file for git upload) and there is still some danger of uploading this file to a place where it should not be... The other option was to keep the database settings for your live and dev server in sync - also not easy and maybe not the best... My solution is as simple, fast and I think it should be even safer than the other options. Just put these lines at the end of your config.php file: if(strpos($config->paths->root, 'C:/www/') === 0) { $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER[HTTP_HOST]]; $config->debug = true; } elseif(strpos($config->paths->root, '/var/www/vhosts/') === 0) { $config->httpHosts = []; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->debug = false; /** * Redirect to HTTPS * ATTENTION: This will NOT work with ProCache enabled! Use .htaccess instead */ if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "off"){ $redirect = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']; header('HTTP/1.1 301 Moved Permanently'); header('Location: ' . $redirect); exit(); } } else die('wrong config.php'); Having a separate config-dev.php file also makes it necessary to keep both files in sync. That was my first idea: To include the original config and then overwrite settings. But it's just simpler the other way round: Using the default config.php file and overwriting settings there.