[
https://issues.apache.org/jira/browse/JAMES-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409803#comment-17409803
]
Benoit Tellier commented on JAMES-3643:
---------------------------------------
This approach would not work if you manage two distinct domains (or more) and
want a clear split between them.
example:
We have :
{code:java}
bob@customer1
alice@cusomerb
{code}
We want (as there are no ambiguity) logins to work with:
{code:java}
bob
alice
{code}
However the following should be rejected (as it can be seen as identity
stealing):
{code:java}
bob@customerb
alice@customera
{code}
The "no virtual hosting with default domain" approach do not allow such
distinctions.
Does it answers your question?
Regards
Benoit
> VirtualHosting: using both [email protected] and bob as a connection identifier
> ----------------------------------------------------------------------------
>
> Key: JAMES-3643
> URL: https://issues.apache.org/jira/browse/JAMES-3643
> Project: James Server
> Issue Type: Improvement
> Components: IMAPServer, POP3Server, SMTPServer, UsersStore &
> UsersRepository
> Affects Versions: 3.6.0
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Following this message:
> https://www.mail-archive.com/[email protected]/msg70640.html
> This is a problem I had during the last deployments I did carry over:
> explaining people their credentials were *[email protected]* and not *bob* as
> they had the habit of. (A I turn on virtual hosting then I do need to have
> the domain name for usernames)
> Recently I and my team at Linagora had been tasked to support both *bob* and
> *[email protected]* connection identifiers for the POP3 protocol, which we did
> implement in a private (tailor-made) project.
> However, we strongly believes this would also benefit the Apache project as
> well (removes some barriers for the initial migration), thus would propose
> adoption here too.
> h3. Design
> - *UsersDAO* class can list username with a given localpart
> - *UsersReposiotry::getUserByName* could then attempt a resolution when
> virtualhosting is enabled but the username is only a local part:
> - The list of user with that local part is empty -> not found
> - The list of user with that local part have one item -> return it
> - The list of user with that local par several items -> fail
> (ambiguous)
> - We then adapt SessionProvider to rely on that code path
> Local part resolution for JPA and Memory is trivial, requires one projection
> with Cassandra, requires one more configuration field (uid) for LDAP.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
