Leaderboard

The traveling over the last month or so is finally finished. In late September/early October my family traveled to Spain, France, and Italy for the first time. And the last couple weeks my wife and I were in Holland on a bike trip where we lived on a boat for a week and biked all over the Netherlands (~150 miles of biking), and got to see a large portion of it. Our forum administrator @Pete was also there, as was Jan, who maintains our website on AWS, so sometimes it felt like a mini ProcessWire meetup too. The trip was one from Tripsite, a company using ProcessWire for more than 15 years, and this trip was their 25th anniversary. There were about 30 other people there as well, several whom also work ProcessWire as editors. It was an amazing trip, and now I'm completely sold on bike and boat trips being the best way to experience a country. I felt like I was a resident rather than a tourist. I’m sorry there have not been a lot of updates here lately due to all of the travel, but now that it’s done, it’s time to get back to work on our next main/master version, which I’m greatly looking forward to. While there have only been 3 commits this week, there have been 25 commits since 3.0.241, so I’m bumping the dev branch version up to 3.0.242, to get the momentum going again. Thanks for reading, and for your patience while I catch up with communications and such, and have a great weekend! Below is a photo of Pete, Jan and Ryan on the boat in Amsterdam.

Chill 😅 You could post little travel logs instead next time 😉

I needed to do this and thought the code might be useful for others too. In my case the organisation has a main site (Site A) and a related but separate site (Site B). The objective is for the users at Site B to be automatically kept in sync with the users of Site A via PW multi-instance. Users are only manually created or deleted in Site A. Both sites have the same roles configured. // InputfieldPassword::processInput $wire->addHookAfter('InputfieldPassword::processInput', function(HookEvent $event) { /** @var InputfieldPassword $inputfield */ $inputfield = $event->object; $input = $event->arguments(0); /** @var UserPage $page */ $page = $inputfield->hasPage; if($page->template != 'user') return; // Return early if there are any password errors if($inputfield->getErrors()) return; // Get the new password as cleartext from $input $pass = $input->get($inputfield->name); if(!$pass) return; // Set the password as a custom property on the Page object $page->newPass = $pass; }); // Pages::saved $pages->addHookAfter('saved', function(HookEvent $event) { /** @var UserPage $page */ $page = $event->arguments(0); if($page->template != 'user') return; if($page->isUnpublished()) return; // Update or create user in Site B $site_b = new ProcessWire('/home/siteb/siteb.domain.nz/', 'https://siteb.domain.nz/'); /** @var UserPage $u */ $u = $site_b->users->get($page->name); // Create a new user if none exists with this name if(!$u->id) $u = $site_b->users->add($page->name); // Set the password if the custom property was set in the InputfieldPassword::processInput hook if($page->newPass) $u->pass = $page->newPass; // Set email address $u->email = $page->email; // Set roles $u->roles->removeAll(); foreach($page->roles as $role) { $u->addRole($role->name); } $u->save(); }); // Pages::deleteReady $pages->addHookAfter('deleteReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); if($page->template != 'user') return; // Delete user in Site B $site_b = new ProcessWire('/home/siteb/siteb.domain.nz/', 'https://siteb.domain.nz/'); $u = $site_b->users->get($page->name); if(!$u->id) return; $site_b->users->delete($u); }); This assumes the use of the default "user" template and not an alternative template. In my case the user template only has the default fields, but the code could be adapted if you have additional fields in your user template. This doesn't handle renaming of users as that's not something I have a need for. But there would be ways to achieve this too, e.g. store the user ID for Site B in a field on the user template in Site A, and then get the Site B user by ID rather than name.

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.

How did you use to do it? I think most of our solutions should apply to any PHP based CMS.

Thanks for posting @omshah. I was also a part of this assessment group, in my day job I work on antarctica.gov.au, and several other large Processwire sites. What are the impacts of having it enabled by default? Is it just extra overhead? Certainly agree that permissions changes should be logged somewhere for accountability purposes. Not sure if it should be a new log, or part of the session log? Maybe different is best. Upon reflection, I think you're right here @teppo - I think 429 is best returned for legitimate (authenticated) responses to something like an API to indicate that whilst successful and allowed, the rate limit has been exceeded. It is best to hide the fact any security actions have occurred. Overall Processwire is so solid, I've used it for over 12 sites now. Everything from small business to large government entities - it's such a blast to work with.

@Ivan GretskyI used to do Cowboy Coding (just learn the term! Love it) all the time, using Cloud9, so I only needed my browser to code. Then I switched to VsCode and remote development, but extensions started eating up my small server instance's memory (The default @builtin TypeScript extension is a RAM monster! and I wasn't even using it!). I spend half my time monitoring server-side extensions... until I finally made the switch to DDEV. That's definitely in my next-to-try list @bernhard

I am not a deep diving webdev like many of you. With WP I learnt many things about Bootstrap (used it via Livecanvas Builder) and build some things with CSS frameworks (Pure and Bulma). I decided to build my own website with another tool from ground up with pw;-) Since PW is available via Softaculous for the first steps its ok (install, db, and try pw admin), since it installes the intermediate site-profile, but then I wanted to go through the Pw install process itself, tested around, installed pw many times, installed different site-profiles to discover the different output strategies and tested @bernhards cool site-rockfrontend. And enjoy this friendly community with soooo many hints and ideas, even for PW beginners. Really great.

First of all, you’ve got some solid suggestions here. Thanks for sharing. Just a couple of notes: Agreed, IP based blocking should be enabled by default. I did notice that you said this was tested with the default settings, but it should be noted that IP blocking is an option that can be easily enabled. I do not agree with your second suggestion, though. In fact the system should preferably try to make blocked requests look exactly the same (and take exactly the same time) as those that were not blocked. Strictly from security point of view, that is; compromises often have to be made to meet user expectations. Though I definitely appreciate the sentiment, this is not really realistic requirement, in my opinion. HTTPS is always a good idea and available in most cases, but this could become an issue e.g. considering development environments. As such, I feel that current default makes a lot of sense, all things considered. And again, thanks for sharing your findings!

https://processwire.com/docs/security/admin/#preventing-dictionary-attacks For sites with simultaneous users coming from the same shared IP address, throttling by IP address may lock out legitimate users. Had this scenario with a project with about 1.000 frontend user accounts, which could sign in for courses. All get an E-Mail with their login credentials at about the same time. We had about 50-100 users from a big company using a shared IP address. Here some (5-10) of those users where blocked. So I allowed some IP ranges to not lock out legitimated users sharing the same IP address, simply to reduce the support request for my clients site operators. If this scenario doesn‘t matter for your sites, I would always turn on throttling by IP address.

Hey @olivetree! You can use Remote development plugin for VS Code. This way you can work on your staging (or prod if you like cowbow coding)) from a locally installed VS Code via ssh. It install VS Code server on a remote machine and connects to it. So you do not need to have anything but VS Code locally. There is similar thing in PhpStorm I know nothing more about)

Thanks for sharing! That's a nice setup I get it now! I Wouldn't these tools support ProcessWire? (I remember it being available on Softaculous) Or are some parts of these tools tightly integrated with Wordpress/Bludit?

Interesting thread. I'll add RockMigration deployments to the mix. I'm working on a video about it 🙂 And I'll probably improve the process along the way...

Many thanks @bernhard. Now I understand the mechanism behind. I didnt realized that this way changes are collected and rebuild into tailwinds css file(s).

Hey @olivetree my site profile uses NPM to install tailwind and tailwind is used for all the utility classes like "mt-5" or "py-2" etc.; Whenever you run "npm run build" this process is started and it creates a css file that you can then load on your webpage. In my profile this is usually done whenever a file changes (from /site/livereload.php). If you don't modify your markup on your production system this file will never ever change, so you can just upload that file and that's all you have to do. If you don't need to recompile the file you don't need npm on the remote server.

May want to pass ['noHooks' => true] to the save() call to prevent the hook from being called recursively: https://processwire.com/api/ref/pages/save/ (I also like the 'quiet' option).

Thanks @Noboru for the pointer! I've released version 0.3.1 with your suggested fix.

Running latest ddev version on Windows 11 under wsl2. No slow down seen yet compared to previous versions.

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.

Hi I use on a webhosting equipped with a Litespeed webserver (not OpenLiteSpeed), which seams to be compatible with the .htaccess rules to Apache one. Everything seams to be working fine. But I ask myself if I should setup customer sites on Litespeed or better pure Apache. Some questions I am asking myself: Do definied rules of Apache 2.2 and 2.4 working together? Or does this just work out of the box for all Pro and other modules? Does anyone has some deeper technical experience if there are any incompabilities or expected problems between the rules and directives of apache and litespeed? Many thanks for some insights;-)

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

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 🙂