-
-
Notifications
You must be signed in to change notification settings - Fork 11.2k
fix(mail): stringify defaultFromEmail before passing to getAddressFromString #25594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
fix(mail): stringify defaultFromEmail before passing to getAddressFromString #25594
Conversation
WalkthroughgetFromAddress in GhostMailer.js now converts the Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…mString
When no from address is provided (e.g., when sending staff device verification
emails), getFromAddress() sets requestedFromAddress to
emailAddress.service.defaultFromEmail which returns an object {address, name}.
This object was then passed directly to getAddressFromString() which calls
EmailAddressParser.parse(from) internally. However, parse() expects a string
input and returns null when given an object, causing email sends to fail.
This bug affects all transactional emails that dont explicitly specify a from
address, including staff device verification (2FA) emails, password reset
emails, and member magic link emails.
The fix converts the email object to a string using EmailAddressParser.stringify()
before passing it to getAddressFromString().
Also adds a test case to verify this behavior.
The test was checking for 'Ghost' in From.Name and 'test@example.com' in
From.Address, but these expectations don't match the actual code behavior:
1. From.Name should be the site title ('Test Blog' set via UserFactory),
not 'Ghost'. The name 'Ghost at [domain]' is only used as a fallback
when no site title is configured.
2. From.Address should be the noreply address derived from the site URL
(noreply@localhost for local tests), not 'test@example.com' which
is the admin user's email, not the mail.from config.
Updated the test to check for the correct expected values.
c4d657f to
831a6bd
Compare
Summary
This PR fixes a bug in
GhostMailer.jswhere transactional emails fail to send when no explicitfromaddress is provided.The Problem
In
getFromAddress()(line 32-51), whenrequestedFromAddressis not provided, the code sets:However,
defaultFromEmailreturns an object{address: string, name: string}, not a string.This object is then passed to
getAddressFromString(requestedFromAddress, ...)which internally callsEmailAddressParser.parse(from). Theparse()function expects a string input and returnsnullwhen given an object:This causes downstream failures when trying to access
addresses.from.nameon a null value.Impact
This bug affects all transactional emails that don't explicitly specify a
fromaddress:staffDeviceVerificationis enabledThe error message shown to users is unhelpful: "Failed to send email. Please check your site configuration and try again." - even when the SMTP configuration is correct.
The Fix
Convert the email object to a string using
EmailAddressParser.stringify()before passing it togetAddressFromString():Test Added
Added a test case in
GhostMailer.test.jsthat verifies emails are sent correctly when nofromaddress is provided, which exercises thedefaultFromEmailcode path.Test Plan
staffDeviceVerificationin configReproduction Steps (for the bug)
staffDeviceVerification: truein configNote
Fixes sender handling by stringifying defaultFromEmail when no from is provided; adds unit coverage and updates e2e expectations for welcome email sender.
getFromAddressinghost/core/core/server/services/mail/GhostMailer.jsto stringifyemailAddress.service.defaultFromEmailviaEmailAddressParser.stringifywhenfromis missing.ghost/core/test/unit/server/services/mail/GhostMailer.test.jsverifying correct default sender ("<site title>" <noreply@<domain>>) when nofromis provided.e2e/tests/public/member-signup.test.tswelcome email assertions to expectFrom.Namecontains site title andFrom.Addresscontainsnoreply@.Written by Cursor Bugbot for commit 831a6bd. This will update automatically on new commits. Configure here.