mirror of
https://github.com/SuiteCRM/SuiteCRM.git
synced 2026-03-02 19:16:58 -05:00
HTML entities in SMTP password #4291
Labels
No labels
Area: API
Area: Campaigns
Area: Cases
Area: Clean Up
Area: Clean Up: Performance
Area: Dashlets
Area: Databases
Area: Developer Tools
Area: Elasticsearch
Area: Elasticsearch
Area: Emails
Area: Emails:Campaigns
Area: Emails:Cases
Area: Emails:Compose
Area: Emails:Config
Area: Emails:Templates
Area: Environment
Area: Installation
Area: Language
Area: Mobile
Area: Module
Area: PDFs
Area: PHP8
Area: Reports
Area: Studio
Area: Styling
Area: Upgrading
Area: Workflow
Area:Activity Stream
Area:Calls
Area:Import
Area:Projects
Area:Search
Area:Surveys
Area:Themes
Area:Users
Branch:Hotfix
Good First Issue
Hacktoberfest
Help Wanted
PR:Community Contribution
PR:Type:Enhancement
Priority:Critical
Priority:Important
Priority:Moderate
Severity: Major
Severity: Minor
Severity: Moderate
Status: Requires Code Review
Status: Requires Updates
Status: Stale
Status: Team Investigating
Status:Assessed
Status:Fix Proposed
Status:Needs Assessed
Status:Requires Automated Tests
Type: Bug
Type:Deprecated
Type:Discussion
Type:Duplicate
Type:Invalid
Type:Question
Type:Suggestion
Type:Suggestion
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/SuiteCRM-SuiteCRM#4291
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @josedpedroso on GitHub (May 12, 2020).
Originally assigned to: @samus-aran on GitHub.
Issue
SuiteCRM encodes the password for the SMTP server with HTML entities.
Expected Behavior
SuiteCRM should send the SMTP password exactly as typed.
Actual Behavior
SuiteCRM sends the password with some special characters encoded as HTML entities, like &g t; instead of >
Authentication therefore fails, no mail is sent.
Steps to Reproduce
Context
Spent far too much time trying to figure out why any email client could send using my SMTP server, but not SuiteCRM.
Your Environment
@chris001 commented on GitHub (May 12, 2020):
Excellent find!
@tsmgeek commented on GitHub (May 13, 2020):
Are you sure this happens all the time or only with the test email send in the outgoing mail?
No
html_entity_decodeas it never passes though a Bean.@josedpedroso commented on GitHub (May 13, 2020):
I had only tried the test in the settings page, but went back just now and sent a test campaign. It also happens with a scheduled mass mail campaign.
@josedpedroso commented on GitHub (May 14, 2020):
I added the following line to the beginning of sendEmailTest() in /modules/Emails/Email.php and it shows the issue right in my PHP log file.
error_log(print_r(func_get_args(), true));@pgorod commented on GitHub (May 14, 2020):
I suggest a troubleshooting technique here
https://community.suitecrm.com/t/outbound-email-password-save-issue/72871/2
(in case it's related to XSS clean-ups, I'm not sure it is)
@josedpedroso commented on GitHub (May 14, 2020):
I added
error_log($this->mail_smtppass);to the beginning of getValues() in /include/OutboundEmail/OutboundEmail.php, and then saved SMTP settings in the admin page. It showed the issue in the log too, so the password is already wrong when it reaches the database. Before that, there's populateFromPost(), which gets values straight from $_POST. I wonder why values from $_POST are getting mangled. Magic quotes were deprecated for very good reasons. Then I looked at save():$q = sprintf("INSERT INTO outbound_email (%s) VALUES (%s)", implode(",", $cols), implode(",", $values));and now I know why SuiteCRM uses its own magic quotes.
@tsmgeek commented on GitHub (May 14, 2020):
Internally SuiteCRM uses
$db->quoted()to quote/escape it for saving to DB, that is what thegetValues()method does on L521 in that file.On looking it needs to be fixed in a few places or refactored.
modules/EmailMan/testOutboundEmail.php
modules/Emails/EmailUIAjax.php
There is
from_html()andto_html()methods, maybe it all needs to pass though here.I think as the forms are posted back as
urlencodedeverything has to be decoded first due to XSS protection codeclean_incoming_data()@samus-aran commented on GitHub (Jul 28, 2020):
Just following up from this thread, did we get any further on this? Is it a matter of updating those testOutboundEmail and EmailUiAjax?
@deuks commented on GitHub (Aug 20, 2020):
I'm having this issue on 7.10.27 LTS as well. Is this the same issue as #6332? If so it looks like this issue has stretched back 3 years or so.
@samus-aran commented on GitHub (Sep 15, 2021):
Okay, next steps then is to define what characters we would allow or disallow. It would be good to reference other systems that has this feature and mimic so that SuiteCRM is relatively accepting of pre-existing password from other email clients.
@tsmgeek commented on GitHub (Sep 15, 2021):
Check RFC for SMTP.
@pgorod commented on GitHub (Sep 15, 2021):
We can allow all characters, we just shouldn't do HTML entities substitution for data that is not going to be used as HTML. Our generic clean-ups of everything that is input into the system are just plain wrong.
If some character is not allowed for some more coherent reason (like the RFC for SMTP not allowing it), then we should notify the user, instead of accepting the password and then failing log in...
@SuiteBot commented on GitHub (Jan 10, 2022):
This issue has been mentioned on SuiteCRM. There might be relevant details there:
https://community.suitecrm.com/t/configuracion-email-yahoo-suitecrm8-win10-wampserver/83581/2