This method is used everywhere to try to retrieve the login of the user
(and normally use the return value to [SOGoUser initwithLogin: ...])
In multidomain environments (with DomainLessLogin = false) there were
several paths (mostly in SOGoAppointmentObject.m) that were trying to
create SOGoUser objects with incorrect login: using only the uid part,
not full email. Then like domain based uid was enabled, these users
had DomainLessLogin set to true and further calls tried to authenticate
only with the uid part (and they should not).
This affects to several methods in:
* ActiveSync/SOGoActiveSyncDispatcher.m
* Appointments/SOGoAppointmentFolder.m
* Appointments/SOGoAppointmentObject.m
* Appointments/SOGoCalendarComponent.m
* SOGoSAML2Session.m
Probably a few features related with calendars are now fixed or working
as intended in multidomain environments where the email is used as login
Depend of the current workflow these paths are reached with
username as uid and sometimes as uid@domain. So in multidomain
environments only append @domain when needed.
Depend of the current workflow this paths are reached with
username as uid and sometimes as uid@domain. So in multidomain
environments only append @domain when needed.
Conflicts:
SoObjects/SOGo/SOGoUserManager.m
On multidomain environment (SOGoEnableDomainBasedUID) with email for imap
authentication (SOGoForceExternalLoginWithEmail) we need to use uid@domain
instead of just uid in method getEmailForUID
In multidomain environments this will produce that info@domain1.com
can read info@domain2.com emails when info@domain2.com log in after
info@domain1.com is already logged in.
If multidomain is not enabled, this action is not needed because
uid+attributes has been already saved on shared cache
On multidomain environment (SOGoEnableDomainBasedUID) with email for imap
authentication (SOGoForceExternalLoginWithEmail) we need to use uid@domain
instead of just uid in method getEmailForUID
In multidomain environments this will produce that info@domain1.com
can read info@domain2.com emails when info@domain2.com log in after
info@domain1.com is already logged in.
If multidomain is not enabled, this action is not needed because
uid+attributes has been already saved on shared cache
In multidomain environment right now we are trying to authenticate against
all sources defined in sogo.conf because the domain is not set at this point.
In sogo.conf we have to specify the domain a source is useful for, so with this
patch instead of 'n' tries of authentication we will perform only 1 (in a scenario
where we have 1 source per domain, and we have 'n' domains).
