CMS MADE SIMPLE FORGE

Frontend Users

 

[#12239] Some frontend users cannot reset password

avatar
Created By: Harald Ihle (Harjavaldr)
Date Submitted: Tue Jan 07 14:00:34 -0500 2020

Assigned To: Robert Campbell (calguy1000)
Version: 3.2
CMSMS Version: 2.2.13
Severity: Major
Resolution: None
State: Open
Summary:
Some frontend users cannot reset password
Detailed Description:
PROBLEM
The frontend users who reset their passwords during an earlier version of module
FrontEndUsers (version 2.x?) are not anymore able to do so:
- an e-mail is correctly sent
- clicking on the provided link in the e-mail works OK: a form with a unique
code and 2x password fields is shown
- after sumitting the form, an error message appears, stating that the code is
wrong

WHY THIS HAPPENS
I found a database table 'cms_module_feusers_tempcode' where formerly the unique
code was stored.
Apparently it is not anymore used; all timestamps of the present codes stored
there refer to the time before my recent FEU module upgrades. However it seems
that the table is still checked in FEU module version 3.2, giving the error
message.

FIX
Removing the entries in this database table resolves the problem.

MY SYSTEM
----------------------------------------------

Cms Version: 2.2.13

Installed Modules:

    AdminSearch: 1.0.4
    Album: 1.11
    CGCalendar: 2.6.2
    CGExtensions: 1.65.1
    CGSimpleSmarty: 2.2.1
    CMSContentManager: 1.1.8
    CMSMailer: 6.2.14
    Captcha: 1.0
    CmsJobManager: 0.1.3
    CustomContent: 1.10
    DesignManager: 1.1.7
    FileManager: 1.6.10
    FilePicker: 1.0.4.1
    FormBuilder: 1.0.2
    FrontEndUsers: 3.2
    MicroTiny: 2.2.4
    ModuleManager: 2.1.7
    Navigator: 1.0.9
    Search: 1.51.7
    ThemeManager: 1.1.8
    TinyMCE: 3.3.1


Config Information:

    php_memory_limit:
    max_upload_size: 64000000
    url_rewriting: mod_rewrite
    page_extension:
    query_var: page
    auto_alias_content: true
    locale:
    set_names: false
    timezone: Europe/Amsterdam
    permissive_smarty: true


Php Information:

    phpversion: 7.2.24
    md5_function: Aan (Waar)
    json_function: Aan (Waar)
    gd_version: 2
    tempnam_function: Aan (Waar)
    magic_quotes_runtime: Uit (Onwaar)
    E_ALL: 22519
    E_STRICT: 0
    E_DEPRECATED: 0
    test_file_timedifference: Geen tijdsverschillen gevonden
    test_db_timedifference: Geen tijdsverschillen gevonden
    create_dir_and_file: 1
    memory_limit: 128M
    max_execution_time: 600
    register_globals: Uit (Onwaar)
    output_buffering: 4096
    disable_functions:
    open_basedir:
    test_remote_url: Succes
    file_uploads: Aan (Waar)
    post_max_size: 128M
    upload_max_filesize: 64M
    session_save_path: /var/lib/php/session (1733)
    session_use_cookies: Aan (Waar)
    xml_function: Aan (Waar)
    xmlreader_class: Aan (Waar)
    check_ini_set: Aan (Waar)
    curl: Aan


Performance Information:

    allow_browser_cache: Aan (Waar)
    browser_cache_expiry: 60
    php_opcache: Aan (Waar)
    smarty_cache: Uit (Onwaar)
    smarty_compilecheck: Uit (Onwaar)
    auto_clear_cache_age: Aan (Waar)

Server Information:

    Server Software: Apache
    Server Api: cgi-fcgi
    Server Os: Linux 2.6.32-754.24.2.el6.x86_64 Aan x86_64
    Server Db Type: MySQL (mysqli)
    Server Db Version: 5.1.73
Server Db Grants: Er is een "GRAND ALL" permissie gevonden, alles lijkt in
orde.


Permission Information:

    tmp: /var/www/vhosts/ag-eindhoven.nl/httpdocs/tmp (0755)
    tmp_cache: /var/www/vhosts/ag-eindhoven.nl/httpdocs/tmp/cache (0755)
templates_c: /var/www/vhosts/ag-eindhoven.nl/httpdocs/tmp/templates_c (0755)
    modules: /var/www/vhosts/ag-eindhoven.nl/httpdocs/modules (0755)
    uploads: /var/www/vhosts/ag-eindhoven.nl/httpdocs/uploads (0755)
Bestandscreatiemasker (umask):
/var/www/vhosts/ag-eindhoven.nl/httpdocs/tmp/cache (0755)
    config_file: 0444

----------------------------------------------


History

Comments
avatar
Date: 2020-02-06 10:28
Posted By: Mathieu Muths (airelibre) (airelibre)

In fact this table is used, but the problem comes when a user tries to recover a
password at leat two times.

This temp code table can only accept 1 temp code as the userid column is primary
/ unique. So when a user tries to recover its password a second time, it fails
as the new temp code is never stored in the db.

I made a workaround on my install removing the primary attribute on the first
column, and removing the foreign key in the table structure. Now a user can try
to recover a password multiple times.
On the other hand, a robot could fill the recover password multiple times and
kind of "saturate" the table.

Hopefully Calguy1000 will find a better solution ;) Thanks