Email.setMailSession() discards provided session if using authentication

• Key: EMAIL-70
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Minor
• Assignee: Siegfried Goeschl
• Reporter: F. Andy Seidl
• Affects Version/s: 1.1
• Fix Version/s: 1.2

Description

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.

Comments

[Ben Speakmon]

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

[Bjorn Townsend]

I've looked into this a bit, and it looks difficult to test. Andy, any chance you could provide a test?

[Siegfried Goeschl]

When mail authentication is required and no username/password is supplied than the provided mail session is used. If a username/password is found the implementation creates a new mail session and a DefaultAuthenticator as convinence implementation.