[#3845] - [#33908] Require password reset can be skipped
- Closed
- 3 Aug 2014
- Medium
- Build: staging
- # 3845
- Diff
- maxvalentini77:staging
- Foreign ID 33908
- Pending JTracker Bug Squad working on it... Details
User tests: Successful: Unsuccessful:
=== Require password Reset can be skipped ===
A user that must reset his password can avoid to be redirected to the profile page and access any page/task if the url contains the parameter layout=edit.
The check code was mostly duplicated on site and administrator application.
I have created a new method in class JAppilcationWeb that manage this check, every application can call this method specifying the page that manage the password reset.
In the site application this check must be done after the "route" because parameters 'option', 'view' and 'layout' can be placed anywhere in the url (due to sef urls).
For symmetry i also placed, in the administrator application, the call to the check method after the "route" method is called.
The page that manage the password reset can now be customized for each application using the configuration.php file.
=== How to reproduce the bug ===
Edit a user, and enable the flag "Require password Reset".
After user login to the backend side, he is required to change his password and he is redirected to http://...website.../administrator/index.php?option=com_admin&view=profile&layout=edit&id=473
Every attempt to browse a different page (even a logoff), ends with a redirection to che password change.
But if the user adds the query string &layout=edit he escapes from the password prompt and actually goes to item editing.
For example, supposing that the article with id=1 exists, write the following url:
http://...website.../administrator/index.php?option=com_content&task=article.edit&id=1&layout=edit
Note the query string &layout=edit at the end of the url
=== Links ===
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33908&start=0
| Title |
|
||||||
| Title |
|
||||||
Done
Also before the conditional here
// Empty task are always permitted
- if (!empty($task) && array_search($task, $tasks) === false)
Done
Looks like this has already been merged.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-08-03 16:20:44 |
I'm going to re-open this item. As noted at #4403 this patch caused unexpected side effects. Let's fine tune this and we can re-apply it.
This comment was created with the J!Tracker Application at http://issues.joomla.org/.
Apparently it can't be re-opened since the source repo's been deleted. Either way, the references are at least present now.
Hi,
I'm looking at what happens.
The problem is present on the site side only.
The com_admin/profile view send back view and layout the com_users/provile view don't send them back, only option and task, so i check the view and the layout only if the task is not specified.
Changing the method to this version resolve the issue:
protected function checkUserRequireReset($option, $view, $layout, $tasks)
{
if (JFactory::getUser()->get('requireReset', 0))
{
$redirect = false;
/*
* By default user profile edit page is used.
* That page allows you to change more than just the password and might not be the desired behavior.
* This allows a developer to override the page that manage the password reset.
* (can be configured using the file: configuration.php, or if extended, through the global configuration form)
*/
$name = $this->getName();
if ($this->get($name . '_reset_password_override', 0))
{
$option = $this->get($name . '_reset_password_option', '');
$view = $this->get($name . '_reset_password_view', '');
$layout = $this->get($name . '_reset_password_layout', '');
$tasks = $this->get($name . '_reset_password_tasks', '');
}
if ($this->input->getCmd('option', '') != $option)
{
// Requested a different component
$redirect = true;
}
else
{
$task = $this->input->getCmd('task', '');
// Check task or view/layout
if (!empty($task))
{
if (array_search($task, explode(',', $tasks)) === false)
{
// Not permitted task
$redirect = true;
}
}
else
{
if ($this->input->getCmd('view', '') != $view || $this->input->getCmd('layout', '') != $layout)
{
// Requested a different page/layout
$redirect = true;
}
}
}
if ($redirect)
{
// Redirect to the profile edit page
$this->enqueueMessage(JText::_('JGLOBAL_PASSWORD_RESET_REQUIRED'), 'notice');
$this->redirect(JRoute::_('index.php?option=' . $option . '&view=' . $view . '&layout=' . $layout, false));
}
}
}
Tested on administrator and site app.
Open a new pull request with the full patch and we'll be good to go.
piotr-cz
- 
Sophist-UK
- 
phproberto
- 
dgt41
- 
rdeutz
-
I can confirm the issue and the PR fixes the problem