14
@ Peekay:Quote:
Mamba, I confess I am a little disturbed by this comment. The user and group permissions features of Xoops is probably the one and only thing that sets it apart from other CMS solutions. It has worked flawlessly for years without any security issues that I am aware of. Tinkering with this and causing a failure (which has clearly happened) is not good to see. Why exactly have these changes been made and to what benefit?.
As I've mentioned in my previous post, it was an improvement to our security. The approaches how to hack systems are changing and improving, so even if this particular part of XOOPS worked fine over years, when we learn about a potential risk, we have to fix it. XOOPS has been always committed to protect our users, and to ensure that XOOPS is the most secure CMS it can be, with no compromises on security.
Quote:
That is very nice, but surely the path change alone will cause many other modules to fail?
No, only those modules that copied and use locally the grouppermform.php, which as Irmtfan said, is not necessarily a best programming practice. But to fix the issue it will take 10 seconds for the user by adding two lines of code.
Quote:
This dependence on 'official' module packs is damaging Xoops reputation as a development platform. This type of change should have been documented *before* this particular version of Xoops was released.
Hmm, why is it damaging? The whole idea about having an "official" module packs was to make sure that our users can be ensured that the most popular modules will be maintained and they don't have to worry about "orphaned" modules not being compatible with latest XOOPS versions.
The modules that we've tested after that change were working just fine. Only recently I've been made aware that some developers have decided to copy the grouppermform.php file locally. After learning that we've issued a statement and were working on proper instructions on how to fix it by the user.
I agree with you that if there are changes that we know will impact existing modules, we should provide instructions on how to fix it. Originally, based on our testing, we were not aware of any issues, as the change was internal to the Core. It became an issue with modules where developers took parts of the Core and copied it to their local modules, instead subclassing.
Now that we've learned about the situation, we are addressing it.
I am always interested in improving our processes, so what would you do differently here? Your feedback is very much appreciated!