-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
2.6.0, 5.1.2, 5.7
-
55
-
Severity 3 - Minor
-
5
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
Hi everyone
Thank you for your comments and for following this issue. We’ve noticed that this has been raised as both a suggestion CONFSERVER-9443 and as a bug CONFSERVER-59931.
The main causes for the images not rendering properly are all related to the fact that in order to view attachments in Confluence, the user has to be authorised:
the user viewing the email message is not logged in
the user's email client doesn't allow for a session to be set up with Confluence for authentication purposes
the user’s email client no longer has access to the attached image
the configured outgoing mail server caches images, but is unable to authorise in Confluence, and caches the 403 responses (e.g. when Gmail with the default settings is used as the outgoing mail server).
While we don’t have plans to address this currently, we will update this suggestion to be a bug as we understand that images not being viewable in the emails is not an ideal experience and can be confusing for the mail recipient. We’ll also update the linked issues and the description.
Thanks
Makisa | Senior Product Manager, Confluence Server and Data Center
Summary
Images are not shown in email notifications.
Steps to reproduce
- Integrate Confluence with a Mail Server
- Create a test user and ensure that you are watching a space. Additionally, edit the user profile settings to ensure that your mail subscriptions/email settings will ensure that you will be notified for updates.
- Log in as an admin or another test user and create a blog post OR page with no restrictions in the space that your other test user watches so that they will receive an email notification.
Expected behaviour
The email notification would show the attached image.
Actual results
The notification does not display the image attached. You are able to see the content (text) of the notification email but the images are broken. Page is secured with page permissions, so requires a login to view. The images which aren't displayed are attachments on the page. Logging in with Safari and selecting "Remember me" doesn't make a difference.
Notes
The image URLs are the correct relative URLs, but the HTML has a <base> tag in the header.
Workaround
If you're using Google Apps for your organisation you may want to check Google Support. Information is provided for how you can whitelist your Confluence/JIRA base URL to allow it to show embedded images. This is unrelated to mixed http/https content and should be independent of the browser used.
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
CONFCLOUD-9443 Embedded images not shown in email notifications due to login requirement
- Closed
-
- Closed
-
- Gathering Interest
[CONFSERVER-9443] Embedded images not shown in email notifications due to login requirement
Hi team,
Could we (and by we - I mean you 
) implement a mail config checkbox that would allow us to accept this risk?
We only use confluence for our Intranet so there is no security requirement to ensure that the user is a valid user. The fact that they are getting the email is proof that they are valid in our scenario.
In fact, looking at this in more detail, it is only the images that are not included in the email - all of the text is. Surely the text would be more of a risk than any images would be?
Thanks,
Kathryn.
Hi everyone
Thank you for your comments and for following this issue. We’ve noticed that this has been raised as both a suggestion CONFSERVER-9443 and as a bug CONFSERVER-59931.
The main causes for the images not rendering properly are all related to the fact that in order to view attachments in Confluence, the user has to be authorised:
the user viewing the email message is not logged in
the user's email client doesn't allow for a session to be set up with Confluence for authentication purposes
the user’s email client no longer has access to the attached image
the configured outgoing mail server caches images, but is unable to authorise in Confluence, and caches the 403 responses (e.g. when Gmail with the default settings is used as the outgoing mail server).
While we don’t have plans to address this currently, we will update this suggestion to be a bug as we understand that images not being viewable in the emails is not an ideal experience and can be confusing for the mail recipient. We’ll also update the linked issues and the description.
Thanks
Makisa | Senior Product Manager, Confluence Server and Data Center
Atlassian just doesn't know how to fix this. They can't figure it out. It's too complicated. Images, in emails? In 2020? Sounds like sorcery. Why would you expect it to just work? It's not a bug. It's a feature request!
There is no other explanation as to why this has not been fixed in the last 13 years, 2 months, 22 days. They must lack the technical know-how.
Sending emails with broken image links cannot be considered as a (Issue-Type) Suggestion but is a (Issue-Type) Bug!
It's a real pity there is still no fix for this. But if it is too complex or time consuming to fix this, I have a different proposal. Why not add an option to the Mail Server settings to simply strip all images / attachments from email notifications? End users will surely prefer to see no images at all, than to see broken images in their notifications. I have created a separate
feature request for this, please upvote it if you like this new idea: https://jira.atlassian.com/browse/CONFSERVER-59431
I just want to bump a comment from earlier since this is gathering attention still.
If you're using Google Apps for your organization you may want to check the info at https://support.google.com/a/answer/3299041?hl=en about how you can whitelist your Confluence/JIRA base url to allow it to show embedded images. This is unrelated to mixed http/https content and should be independent of the browser used.
This worked perfectly for me - I would love to see this mentioned as a potential fix in a documentation or FAQ page so other people can find it without digging through a comment on a ticket from 13 years ago.
+1 This affects our customers