Leaderboard

This week I was wrapping up the client project I mentioned last week (just launched today here), but did get some updates added to the core as well. Primarily the addition of some smaller feature requests. One of the features added is a README.md and CHANGELOG.md viewer to each module's configuration/info screen. When a module has one of those files in it, it is now viewable from within the admin. You'll see the links them at the bottom of the "Module information" section of any module's config/info screen in the admin. Other requested features added were: Support for OPTIONS, CONNECT and TRACE methods in WireHttp. And, A new hookable method in ImageSizerEngineIMagick added via a PR from Robin S. Support for <hr> elements has been added in InputfieldSelect and InputfieldSelectMultiple. It was news to me, but apparently <hr> (horizontal rule) elements are now supported by browsers between <option> tags in <select> elements, rendering a nice separator between options when you want them. So our Select inputfields now support that. To add a horizontal rule/separator, just add an option with 3 or more dashes/hyphens. Programmatically you would do a call like this when you are between options where you want the <hr> to appear: $inputfield->addOption('---'); Or, if specifying options as text (as you would with Options fields, or several other Fieldtypes), you would just enter a line with 3 or more dashes on it, and nothing else. So if we had an select where you could select a color, and we wanted to separate RGB from the other colors, we could do this on its configuration screen: R=Red G=Green B=Blue --- O=Orange P=Pink C=Cyan Thanks for reading and have a great weekend!

A new vulnerability (CVE-2023-24676) was published last week, detailing how module install can be used to execute code and set up a reverse shell on a site. After going through the post that explains the exploit a couple of times I'm wondering if someone could confirm that I've got it right: First of all it requires that a) web server has write access to the modules directory and b) ProcessWire is configured to allow file uploads, right? The latter is by default true in debug mode, which is also mentioned in aforementioned post as one of the conditions. Built-in module downloading features check the moduleInstall setting (in ProcessModuleInstall class) and I couldn't find any way to circumvent them. For anything bad to happen, user with (presumably) superuser access must type in an URL of a ZIP file with malicious code, or someone must be able to intercept the request and change it. First part seems to be a non-issue, e.g. if a superuser really does that then there's very little that can be done to protect them, while the second part (to my understanding) sounds like it would be very unlikely and quite difficult, at least assuming that requests are passed through HTTPS. According to the post the PHP file in the zip is automatically executed by the system. I find this part a bit strange — I'm not exactly familiar with every involved piece of code, but it doesn't seem like ProcessWire should do that. On the other hand if the file in the package was a properly formatted module class, then this would be more likely, and again probably not something that can be prevented. So, in other words, it seems to me that this vulnerability isn't really a vulnerability — more like a way to use a built-in feature to do potentially harmful actions, of which users are specifically warned about in UI of said feature? Let me know if I got something wrong here, though. If anything, it seems to me that this is a good reminder that it is indeed dangerous to enable file uploads from arbitrary URLs or allow web server to write files that could be executed as PHP (or any other language for that matter, including JavaScript). Only thing that I think we could do better is to set those module file download settings false by default, instead of debug as they are now, just to be extra sure that a developer has indeed intentionally enabled them ?

Then you need to look for the home’s name in the user’s language, either $pages->get(1)->getLanguageValue($user->language, "name"); or $pages->get(1)->localName($user->language);

I’ve never tried myself, but I assume you could achieve this using the “PagefileSecure” option in your template holding the files: Which would then allow you to hook into ProcessPageView::sendFile: $wire->addHookAfter("ProcessPageView::sendFile", function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments("page"); if($page->template == 'admin') return; /** @var Pagefile $file */ $file = $page->filesManager()->getFile($event->arguments("basename")); $page->of(false); $count = (int) $file->filedata("downloadsCount"); $file->filedata("downloadsCount", ++$count); $page->save(); }); And then later on retrieve and display the downloads count.

Yes, exactly. Everything in the vulnerability description after "we require a user account with administrative privileges and the application must have debug mode activated" seems redundant to me. At that point it's game over. Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel. It's up to every superuser to ensure that malicious users cannot get an account with administrator privileges so I don't understand how this vulnerability description adds anything beyond that basic point.

[SOLVED] works! thanks!

Thanks! I'll be able to test that tomorrow afternoon.

Template Access A Process module that provides an editable overview of roles that can access each template. The module makes it quick and easy to see which templates have access control enabled (personally I like to ensure I've enabled it for every template) and to set the appropriate access per template. Usage The Template Access page under the Access menu shows access information for all non-system templates in a table. You can filter the table rows by template name if needed. Click an icon in the table to toggle its state. The changes are applied once you click the "Save" button. Sometimes icons cannot be toggled because of logical rules described below. When an icon cannot be toggled the cursor changes to "not-allowed" when the icon is hovered and if the icon is clicked an explanatory alert appears. A role must have edit access before it can be granted create access. If the guest role has view access for a template then all roles have view access for that template. https://github.com/Toutouwai/ProcessTemplateAccess https://processwire.com/modules/process-template-access/

I received a suggestion from @monollonom that it would make more sense if the module appeared under the Access menu rather than the Setup menu. I agree so I've changed to this in v0.1.5. If you've installed < v0.1.5 and you'd like to have the module under Access then there a couple of ways to do this. First update to v0.1.5 and then either... Uninstall the module, and then reinstall the module so the page will be automatically created under Access during install. Or move the "Template Access" page within the Admin branch from under Setup to be under Access.

Hi all, This is our new website, still based on Processwire since 2015, we are very happy to be able to work with such a good piece of software. Thanks everyone for the support. https://velvetyne.fr You can read more about this new version here https://velvetyne.fr/news/new-website-v3/