Crocoblock / jetformbuilder

74 stars 16 forks source link

Register User Error - "empty_password" although password is given in frontend #438

Open kankadev opened 4 months ago

kankadev commented 4 months ago

Hi,

I have a registration form where the user provides his password and has to repeat it. Every required field is filled and all actions are okay except the "Register User"-Action. In the form records I see these errors: grafik

Here is my field mapping in the form's action "Register User": grafik

Here's the full screenshot of the form record: Firefox_Screenshot_2024-05-12T10-03-15 514Z

Here are all my actions and their order: grafik

I don't use sanitising for the fields "password" and "confirm_password".

Password field: grafik

Confirm Password field: grafik

The password we use for the flow test is always the same: 12345678 I just set a minimum and a maximum lenght for the password fields.

kankadev commented 4 months ago

I found error messages related to Jetformbuilder... Maybe this is relevant too.

[12-May-2024 09:09:03 UTC] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ')' at line 22 for query SELECT 
    `wp_jet_fb_tokens`.`id`, 
    `wp_jet_fb_tokens`.`action`, 
    `wp_jet_fb_tokens`.`hash`, 
    `wp_jet_fb_tokens`.`exec_count`, 
    `wp_jet_fb_tokens`.`limit_exec`, 
    `wp_jet_fb_tokens`.`expire_at`, 
    `wp_jet_fb_tokens`.`created_at`, 
    `wp_jet_fb_tokens`.`updated_at`, 
    `wp_jet_fb_tokens_to_records`.`id` as 'main.id', 
    `wp_jet_fb_tokens_to_records`.`token_id` as 'main.token_id', 
    `wp_jet_fb_tokens_to_records`.`record_id` as 'main.record_id'
FROM `wp_jet_fb_tokens_to_records`

LEFT JOIN `wp_jet_fb_records` ON 1=1 
    AND `wp_jet_fb_records`.`id` = `wp_jet_fb_tokens_to_records`.`record_id`

LEFT JOIN `wp_jet_fb_tokens` ON 1=1 
    AND `wp_jet_fb_tokens_to_records`.`token_id` = `wp_jet_fb_tokens`.`id`

WHERE '1' = '1'
    AND `wp_jet_fb_tokens_to_records`.`record_id` IN (); made by require('wp-blog-header.php'), wp, WP->main, WP->parse_request, do_action_ref_array('parse_request'), WP_Hook->do_action, WP_Hook->apply_filters, rest_api_loaded, WP_REST_Server->serve_request, WP_REST_Server->dispatch, WP_REST_Server->respond_to_request, JFB_Modules\Form_Record\Rest_Endpoints\Delete_Form_Record_Endpoint->run_callback, JFB_Modules\Form_Record\Admin\Table_Views\Records_Table_View->get_prepared_list, apply_filters('jet-form-builder/form-record/list'), WP_Hook->apply_filters, JFB_Modules\Verification\Form_Record\Inner_Module->modify_columns_for_records_page, Jet_Form_Builder\Db_Queries\Query_Builder->query_all
engrrajonahmed commented 4 months ago

+1

Facing the same issue and error. I solved it by changing the field type from "Password" to "Text". Then I used JS to change the type of the field in the frontend. It's working now.

kankadev commented 4 months ago

It's a workaround, thank you. But this should be fixed as soon as possible by the dev team.

kankadev commented 4 months ago

For others who have the same problem: Change the textfield's type from password to text and use JS like this:

document.addEventListener("DOMContentLoaded", function () {
    /**
     * Temporary fix for JetFormBuilder: Toggle password visibility
     */
    const passwordInput = document.getElementById('password');
    const confirmPasswordInput = document.getElementById('confirm_password');
    passwordInput.type = 'password';
    confirmPasswordInput.type = 'password';

});

The "empty_password" error is gone and I can register user now.

But I still have the two other errors:

grafik

Jet_Form_Builder\Exceptions\Query_Builder_Exception - Undefined view - plugins\jetformbuilder\includes\db-queries\traits\with-view.php:38 - [] - 85

Jet_Form_Builder\Exceptions\Query_Builder_Exception - Undefined view - plugins\jetformbuilder\includes\db-queries\traits\with-view.php:38 - [] - 86
supercredit commented 3 months ago

+1 same problem here.

I found that if the Event is changed to "DEFAULT.PROCESS", the empty_password error is gone too. But, it's absolutely not a good practice.

Totally agreed that this should be fixed ASAP.

supercredit commented 3 months ago

@kankadev @engrrajonahmed thanks for your method. A drawback of it is that the password show hide function could not be applied.

mblithium commented 2 months ago

Thanks, we still have this problem with password field. 🥲 It only works if you leave it as a text field.

JetEngine: 3.5.1 JetFormBuilder: 3.3.4.1 JetFormBuilder User Login Action: 2.0.4

davidsierens commented 2 months ago

+1 same problem

obaishawqi commented 2 months ago

+1 same problem

waelelsaid commented 1 month ago

I have the same problem.

LadisWasharum commented 1 month ago

For others who have the same problem: Change the textfield's type from password to text and use JS like this:

document.addEventListener("DOMContentLoaded", function () {
    /**
     * Temporary fix for JetFormBuilder: Toggle password visibility
     */
    const passwordInput = document.getElementById('password');
    const confirmPasswordInput = document.getElementById('confirm_password');
    passwordInput.type = 'password';
    confirmPasswordInput.type = 'password';

});

The "empty_password" error is gone and I can register user now.

But I still have the two other errors:

grafik

Jet_Form_Builder\Exceptions\Query_Builder_Exception - Undefined view - plugins\jetformbuilder\includes\db-queries\traits\with-view.php:38 - [] - 85

Jet_Form_Builder\Exceptions\Query_Builder_Exception - Undefined view - plugins\jetformbuilder\includes\db-queries\traits\with-view.php:38 - [] - 86

This works as a frontend solution, but in the backend the form entry for user registration is saving the user's password as plain text for the admin to see. This is most likely illegal and is basically a keylogger, most people reuse passwords.

I am assuming the crocoblock team do not intent to fix this issue as it has been a while now, does anyone have a proper workaround?

cwinkler8 commented 2 weeks ago

@MjHead can you provide any guidance on when this issue might be addressed? As @LadisWasharum points out, showing the user password in plain text is a clear violation of privacy law and cannot be used.