Leaderboard

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.

Configure the repository cloud provider (gitlab, github, etc) to use pipelines to upload with rsync on commit of main branch. If it's content stuff, I assume I have to go do it manually or create a migration that adds new fields, templates, new pages, etc.

I have no idea but in that case I would start by: 1. Activating debug mode. 2. If you have TracyDebugger go to ProcessWire info Pannel > Clear Session, Cookies, & Modules Refresh. If you don't, install it 😉 3. Just for the sake of it Clear all your caches 4. Log what's happening when the page is saved: Put this in your ready.php $this->addHookBefore('Pages::save', function (HookEvent $event) { $page = $event->arguments(0); bd("Attempting to save: {$page->title}"); }); $this->addHookAfter('Pages::save', function (HookEvent $event) { $page = $event->arguments(0); bd("Saved: $page->title"); }); $this->addHookBefore('Pages::saved', function (HookEvent $event) { $page = $event->arguments(0); $changes = $event->arguments(1); bd($changes, "Changes on $page->title"); }); Check the Dumps:

Hi there. I'm using ProcessWire on Litespeed servers for 10+ years. There are NO compatibility issues. Everything you do with regular Apache you can do on Litespeed too. Google "Litespeed vs Apache" and you can easily find out why you should stay with Litespeed 🙂

2D or 3D in PHP? PHP-GLFW (https://phpgl.net/) GameDev and Real-Time Applications in PHP 3D example: https://phpgl.net/examples/opengl/10-sponza.html Cross-Platform PHP-GFLW works on Window, MacOS and Linux. We also support standalone & portable binaries for MacOS and Windows.

Me too, there are no compatibility issues on any of my sites, some on version 2.5 and 3.

PW running on DDEV local containers for deploying and then a shell script (or sometimes duplicator) to publish to a live server.

I'm with Jan here. I have a local copy of the files I'm working on (templates, modules, assets etc) and then ftp them from VSCode using the SFTP extension. I don't have the files upload automatically when they're saved but my muscle memory for uploading a file on save is good. I've tried using Remote Host in VSCode and occasionally use continuous integration with GitHub but for most of my projects that's overkill.

I always install pw locally. Then I use rsync to push and pull modifications, quick and easy.

I have a local copy that uploads changes via FTP on every save because it’s easy. If I’m just trying stuff out in production I slap “if (user()->isSuperuser())” on it 🤣

Thanks @Robin S , this is fantastic! I'll try to implement that asap and will report back here 🙂 Edit: Worked perfectly, thanks again @Robin S !

You can do something like this: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { /** @var Inputfield $inputfield */ $inputfield = $event->object; $process = $this->wire()->process; // Return early if this is not ProcessPageEdit if(!$process instanceof ProcessPageEdit) return; // The page being edited $page = $process->getPage(); // The field associated with the inputfield, if any // Useful for when the inputfield is in a repeater, as the inputfield name will have a varying suffix $field = $inputfield->hasField; // The page that the inputfield belongs to // Useful for identifying if the inputfield is in a repeater $inputfield_page = $inputfield->hasPage; // Return early if this is not a page we are targeting if($page->template != 'test_combo') return; // Do some check to identify the inputfield by name or field name if($field && $field->name === 'text_1' && $inputfield_page->template == 'repeater_test_repeater') { // Check some other field value if the message depends on it if($page->test_combo->my_date === '2024-10-18 00:00:00') { // Show an error message $inputfield->error('This is a test error message'); } } // Do some check to identify the inputfield by name or field name if($inputfield->name === 'test_combo_my_date') { // Check some other field value if the message depends on it if($page->test_repeater->first()->text_1 === 'hello') { // Show an error message $inputfield->error('Another test error message'); } } });

I'm 99% sure there is no module or editor available that works like that - but a Markdown WYSIWYG would be a great addition. About how many pages are we talking here? In case the number is way lower than 100 pages, a large strong coffee and a nice playlist would be a great start to copy everything over manually. If that's not possible or if there are more pages, you could try to update a real HTML field (TinyMCE nowadays, and not CKEditor anymore). In general this could work like this in a loop: // this duplicates the content in fieldname1 into fieldname2 for all pages with // the template called: templatename $source = "fieldname1"; $destination = "fieldname2"; $template = "templatename"; foreach($pages->find("template=$template") as $p) { // set outputFormatting to 'false' so the plain value is copied $p->of(false); $p->$destination = $p->$source; $p->save($destination); } See: https://processwire.recipes/recipes/duplicate-content-between-fields/ In your case we would need to tweak it a bit more and get the generated HTML first, then drop it into the new $destination field and go from there. BUT... from that moment the client should only be using the CKEditor/TinyMCE field and no markdown anymore.

Just launched my first public Module ? This module allows ProcessWire to send transactional emails via Brevo. Download the latest version: https://github.com/ttttim0709/WireMailBrevo Installation Copy the WireMailBrevo directory into your site/modules/ directory. In the ProcessWire admin, go to Modules > Refresh. Click "Install" next to the WireMailBrevo module. Usage Example usage: $email = $mail->new(); $email->to = 'recipient@somedomain.com'; $email->subject = 'Test #1'; $email->body = 'An example email'; $email->send(); Use of Versions: Check the Brevo dev section for more information about Message versions $email->versions([ [ 'to' => [ [ 'email' => 'bob@example.com', 'name' => 'Bob Anderson' ], [ 'email' => 'anne@example.com', 'name' => 'Anne Smith' ], ], 'subject' => 'This is my version subject line', ], [ 'to' => [ [ 'email' => 'jim@example.com', 'name' => 'Jim Stevens' ] ], 'htmlContent' => "<!DOCTYPE html><html><body><h1>Modified header!</h1><p>This is still a paragraph</p></body></html>", ], ]); Configuration After installing the module, you can configure it by going to the module settings page. You need to provide the following configuration options: Brevo API Key: Obtain this key from your Brevo account settings. Sender Email Address: The email address to be used as the sender. Sender Name: The name associated with the sender's email address.