Closed viryagroupdev closed 7 years ago
Yes, I know exactly what happened. It's all about two security related commits.
The first commit is 4f1525674657193163236c71557d9ccce235c061 "# [MEDIUM] Joomla returns null instead of false in some ACL checks". I addressed a security issue affecting all versions of Joomla! 3 (at least since 3.2, I didn't bother with older versions). I also reported the security issue to the JSST, offered a solution and it was applied in Joomla! 3.6.5.
The second commit is f530c951a5a6073013a4c9638644d3fe00a7e28b "# [HIGH] Checking against method ACL rules (&something) returning an event alias (@whatever) always returns true without evaluating the event alias".
Both bugs did affect the save and apply tasks in controllers inheriting from FOF's DataController. Namely, FOF wouldn't be able to check whether the currently logged in user had core.create privileges. As a result any user, including guest, could save arbitrary data to the database.
The solution to your problem is adding a custom ACL entry in the taskPrivileges array of your Controller. Assuming that you want everyone to submit data to the Controller using apply you need to do $this->taskPrivileges['apply'] = true; in your constructor. Otherwise you can override the function getACLForApplySave since this is exactly what is being called when evaluating the ACL privileges for the apply and save tasks (that's what the ampersand notation does in the taskPrivileges array). Or you could have the apply task call your custom method by doing: $this->taskPrivileges['apply'] = '&customApplyAclMethod'; and then create a protected method customApplyAclMethod() which takes no arguments and returns an ACL definition (either an @-notation to have FOF look at a different taskPrivileges entry, a Boolean value to allow/forbid access or the name of a Joomla ACL privilege, either a core one like core.create or a custom one such as acme.rocket.launch).
Nicholas K. Dionysopoulos • Director and Lead Developer Akeeba Ltd 51 Metochiou Str., Flat 303, 1101 Nicosia, Cyprus https://www.AkeebaBackup.com [https://www.akeebabackup.com/] On 7/1/2017 14:12:30, viryagroupdev notifications@github.com wrote: In our fof3 based component we have a custom account creation process which is now broken on the first step when using fof 3.0.17. Reverting to 3.0.15 will yield the desired behaviour The view displays fine index.php?option=com_weconnect_business&view=Registration&layout=self The form submission / "apply" task, which works fine in fof 3.0.15 and before, results in a 403 after upgrading to 3.0.16 or higher (3.0.17 ) Posts to
thanks nik for the time to explain, gonna digest that ;)
In our fof3 based component we have a custom account creation process which is now broken on the first step when using fof 3.0.17. Reverting to 3.0.15 will yield the desired behaviour
The view displays fine index.php?option=com_weconnect_business&view=Registration&layout=self
The form submission / "apply" task, which works fine in fof 3.0.15 and before, results in a 403 after upgrading to 3.0.16 or higher (3.0.17 )
Posts to
After rendering
Any thoughts on what happened and how to correct