Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <5729102.1195675483083.JavaMail.jira@brutus>
Date: Wed, 21 Nov 2007 12:04:43 -0800 (PST)
From: "Ben Speakmon (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (EMAIL-70) Email.setMailSession() discards
 provided session if using authentication
In-Reply-To: <32421952.1195673622995.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/EMAIL-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544583 ] 

Ben Speakmon commented on EMAIL-70:
-----------------------------------

Thanks for the report -- can you provide a test case and a patch? That'll make it much easier to get this addressed.

> 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.