Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/03/2024 in all areas

  1. This powerful module has been under ongoing development for several years. The history dates back to the year 2016 🤯 Back then it was built on top of https://datatables.net/. Later I switched to https://www.ag-grid.com/ and finally settled with https://tabulator.info/ to do the heavy lifting. With RockGrid you can display any kind of tabular data on the ProcessWire backend. It helps you structure your code in a way to keep it maintainable and it comes with a lot of helpers that customise tabulator to the needs of ProcessWire. Download & Docs: baumrock.com/RockGrid
    5 points
  2. 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.
    1 point
  3. RockForms v2.1.0 Breaking Change: RockForms was refactored to use RockLoaders for loading animations. If you have not used any loading animations in your project you should be safe to just upgrade without issues. If you have any problems let me know in the forum! Added getData() method to improve API usage for multi-step-forms
    1 point
  4. RockPageBuilder v5.9.1 Added a config setting to prevent loading the frontend styles file as requested by nurkka here Added block type to the API for filtering/finding as requested by gebeer here and updated docs Added new block icons thx to FireWire's post here. Thank you! 🚀 Improved docs about sort/groupSort
    1 point
  5. RockMigrations v5.5.0 Added PR #65 from lemachinarbo that improves the moduleInstall command; Thank you! 🚀 Added support for config migrations: See docs This update is extremely helpful and from now on the recommended way to write migrations, as this workflow makes circular references a problem of the past! 🥳💪 Added docs about automated releases
    1 point
  6. Ryan - it was great to meet you and Jan in person finally after 12 years 😊 That was a fantastic trip with a great group of people through some really interesting locations. We were pretty lucky with the weather too!
    1 point
  7. I have recently had the same experience. In my case it looked like the culprit was DevSense PHP Tools. I gave up on it but the problem persisted with PHP Intelephense. Finally I gave up and went back to local development and set up a CICD with GitHub Actions which watches my main branch and pushes stuff to the server when main branch is updated. Works a treat!
    1 point
  8. I also like the "cowboy coding" term, but I want to add that VSCode remote can not only be used for cowboy coding but also for - I don't know how to say - regular tasks! I'm using it on a regular basis to do different things on my servers that I manage. It's great, for example, for editing files that are not part of the automated deployment - eg /site/config-local.php Browsing files, moving folders, searching for keywords in the codebase, temporarily adding something to the codebase, etc.; All of that is extremely comfortable to do with VSCode compared to doing it on the command line. So it's definitely a tool that is worth to have and worth to know!
    1 point
  9. 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.
    1 point
  10. In case you really need to build tailwindcss without node and running npm install for whatever reason you can use this https://tailwindcss.com/blog/standalone-cli. Just download a binary, put it somewhere and call with proper arguments. To make it easy in VS Code create a task.
    1 point
  11. 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.
    1 point
×
×
  • Create New...