[
https://issues.apache.org/jira/browse/EMAIL-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550882
]
Bjorn Townsend commented on EMAIL-70:
-------------------------------------
I've looked into this a bit, and it looks difficult to test. Andy, any chance
you could provide a test?
> Email.setMailSession() discards provided session if using authentication
> ------------------------------------------------------------------------
>
> Key: EMAIL-70
> URL: https://issues.apache.org/jira/browse/EMAIL-70
> Project: Commons Email
> Issue Type: Bug
> Affects Versions: 1.1
> Environment: All
> Reporter: F. Andy Seidl
> Priority: Minor
>
> The Email.setSession(Session aSession) method does NOT use the provided
> session value if the provided session is an authenticated session. In that
> case, a new Session instance is created and used instead. The newly created
> session uses a DefaultAuthenticator based on the username/password properties
> provided in the original session.
> This is a problem because the original session may have been created with a
> valid authenticator but without placing the password in the session
> properties. In this case, the newly constructed session will not work. Or,
> the original session may have been created with a custom authenticator, so
> again, the newly constructed session will not work.
> It seems to me that setSession() should simply set the provided session and
> not attempt to be smart about authentication. However, for backward
> compatibility, an improvement would be to offer a setRawSession() that simply
> sets this.session. Another improvement would be to also check for the
> presence of username and password properties before deciding to create a new
> session instance. If either of those properties is missing, use the provided
> session as-is.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
