Project

General

Profile

Actions

Bug #3196

closed

Joomla core user update events not called when updating User object on activation events, blocking in Backend, approval in backend, confirmation, new password in frontend and when emailing password in backend too

Added by mariusvr almost 13 years ago. Updated almost 13 years ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
Start date:
27 January 2012
Due date:
% Done:

100%

Estimated time:
3:00 h

Description

The joomla core events are bypassed on certain user actions by CB. This is because a SQL statement is executed, rather than calling the Joomla JUser API. The problem comes when people have Joomla user plugins installed that depend on the joomla user events. They never get called by CB, meaning these user plugins do not function correctly (whereas it functions when CB is not installed).

Example:
-New user registers and some form of confirmation is required.
-User clicks on the activation link, but CB directly updates the database (bypassing Joomla user plugins)
-Result with JFusion would be that the user remains blocked in linked softwares, despite the user being active in the Joomla database.
-End-user gets confused and site-admin has to spend time manually activating accounts or given user instructions.

The same goes for updating passwords in CB

Search of the CB code revealed a couple of places where #__user table is updated directly (search in eclipse with regex "UPDATE#__users")

cb/controller/controller.default.php
1,026: $_CB_database->setQuery( "UPDATE #__users SET block = " . (int) $actionValue . " WHERE id = " . (int) $row->id );

library/cb/cb.tables.php (4 matches)
1,252: $this->db->setQuery( "UPDATE #_users SET password=" . $this->db->Quote( $this->hashAndSaltPassword( $this->password ) ) . " WHERE id = " . (int) $this->id );
1,546: $_CB_database->setQuery( "UPDATE #
_users SET password=" . $_CB_database->Quote($pwd) . " WHERE id = " . (int) $this->id );
1,689: $query = "UPDATE #__users SET password = '"
1,715: $query = "UPDATE #__users SET password = '"

comprofiler.class.php
839: $query = 'UPDATE #__users'

comprofiler.php
925: $sql = "UPDATE #__users SET password = " . $_CB_database->Quote( $newpass ) . " WHERE id = " . (int) $user_id;

Would you please be able to replace these calls with code that calls the joomla user events (through JUser API for instance)

Thanks, Marius


Files

3196-p1.patch (4.16 KB) 3196-p1.patch krileon, 30 January 2012 20:24
3196-p2.patch (870 Bytes) 3196-p2.patch krileon, 30 January 2012 20:24
3196-p3.patch (1.73 KB) 3196-p3.patch krileon, 30 January 2012 20:24
3196-p4.patch (1.3 KB) 3196-p4.patch krileon, 30 January 2012 20:24
3196-p1_rev1.patch (7.54 KB) 3196-p1_rev1.patch krileon, 01 February 2012 21:38
3196-p1_rev2.patch (3.18 KB) 3196-p1_rev2.patch krileon, 14 February 2012 01:00

Updated by krileon almost 13 years ago

Updated the storePassword function to attempt to store the user through their cmsuser, it has recursive fallbacks and if cmsuser fails it'll use direct database as it did before. Also implemented a new function that does the same thing except for the Block column. Implemented both through CB where _user was directly altered.

Actions #2

Updated by beat almost 13 years ago

  • Status changed from Resolved to Assigned
  • Assignee changed from beat to krileon
  • % Done changed from 100 to 20
  • Estimated time set to 3:00 h

Hi Kyle,
Reviewed patches:

Base analysis is right, but we need to use CB's comprofilerUser ($this) object (which will trigger all CB and joomla ones) and not directly Joomla's. That way CB triggers are also triggered. We need to review and deeply test if this brings regressions with it or not (maybe it will fix even other bugs).

Please propose new (well tested) patches for this bug.

Actions #3

Updated by beat almost 13 years ago

  • Target version set to CB 1.8
Actions #4

Updated by krileon almost 13 years ago

CB triggers execute in saveSafely, but we can't use saveSafely without it triggering validation warnings which will occur because we're only changing and storing the password. ->store() only executes Joomla triggers. All patches except p1 are still valid, updated p1 to use ->store() instead and added profile update triggers. First a new instance of the user is created, because if we just store $this then if other variables were changed they'd also get stored, but we only want to store password for example; then password of the new user instance is changed and stored.

Actions #5

Updated by beat almost 13 years ago

This is a too large change for the RC, but we will try it in test-team and with Marius just after RC to see if all ok for Stable.

Actions #6

Updated by krileon almost 13 years ago

Other patches are still valid. Rev2 proposes a single function to handle the storage and trigger part. Needs review to ensure is the appropriate direction to go.

Actions #7

Updated by beat almost 13 years ago

  • Subject changed from Joomla core user events not called on activation to Joomla core user update events not called when updating User object on activation events, blocking in Backend, approval in backend, confirmation, new password in frontend and when emailing password in backend too
  • Status changed from Resolved to Closed

r1753 implements proposed patches with bug-fixes on patches, but needs thorough testing of:
- activation events in front and backend,
- blocking in Backend,
- approval in backend,
- confirmation of email,
- new password in frontend and
- when emailing password in backend too on new user creation (leaving password blank and CB configured to send email).

Actions

Also available in: Atom PDF