Fix Spaces in passwords are not handled correctly when adding servers

[Shadow243]

Issue Description

I encountered an issue where spaces in passwords were being encoded as + when submitting a POST request with the Content-Type application/x-www-form-urlencoded. This behavior was causing problems, as passwords with spaces were not processed correctly on the server.

Proposed Correction

To address this issue, I added URL decoding (urldecode()) to the server-side code to properly decode data received from the POST request. This ensures that spaces in passwords are correctly handled and not transformed into + symbols. As a result, passwords containing spaces are now processed as expected.

Steps to Reproduce

1. Submit a POST request with Content-Type application/x-www-form-urlencoded.
2. Include a password with spaces in the request data.
3. Observe that the spaces are correctly decoded on the server side.

This change should resolve the issue as described in Issue #821 and ensure that passwords with spaces are handled correctly in POST requests.

[kroky]

@Shadow243 the problem is not the content type as PHP handles content types correctly by decoding incoming encoded types in POST, GET, etc. arrays. The problem should be the FILTER_UNSAFE_RAW filter applied on imap_pass field specified in modules/imap/setup.php . That filter seems to encode special characters. We don't want any encoding or changes in password fields - just ignore anything as a filter - we need the password as user submitted it.

[Shadow243]

Copy that, I'm checking it out...

[Shadow243]

After conducting checks by modifying or removing the filter, it seems that the issue might originate from the encoding done at line 182 of the modules/core/site.js file. The line xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); specifies an encoding that replaces non-alphanumeric characters, such as spaces, with the "+" symbol.

By adjusting the content type from "application/x-www-form-urlencoded" to "multipart/form-data," the data is no longer encoded. However, this change alters the structure in Cypht, bringing us back to the previously suggested solution if preserving the existing structure is desired.

The comment also references a list of tested filters, sourced from filter.constants.php and filter.filters.sanitize.php. After conducting thorough tests, it has become evident that the undesired transformation is indeed linked to the "application/x-www-form-urlencoded" encoding.

Additional Information

• Tested filters: filter.constants.php and filter.filters.sanitize.php.
• Confirmed issue with encoding: "application/x-www-form-urlencoded".

[kroky]

@Shadow243 can you try submitting a normal browser form element with application/x-www-form-urlencoded enctype and see if the variable on the cypht backend is still badly encoded? If so, we should definitely fix site.js encoding function format_xhr_data, so it works with PHP decoding system.

[Shadow243]

@Shadow243 can you try submitting a normal browser form element with application/x-www-form-urlencoded enctype and see if the variable on the cypht backend is still badly encoded? If so, we should definitely fix site.js encoding function format_xhr_data, so it works with PHP decoding system.

Trying this one, not getting transformed data with +.

An alternative solution from: https://itecnote.com/tecnote/jquery-serialize-converts-all-spaces-to-plus/ is working.

Changes can be seen here: #822