På tirsdag 08. juni 2021 kl. 16:02:22, skrev Jean Helou <jean.he...@gmail.com 
<mailto:jean.he...@gmail.com>>: 
Hello Andreas,

 We have an environment where usernames can be *any* character thus the
 > rules enforced by Username does not apply to us. We were thinking about
 > subclassing it, until we saw it has a private constructor signaling that it
 > isn't meant for extending.
 >

 Do you mean org.apache.james.core.Username ? 



 Yes. 


If I understand correctly, the only character restriction there is you
 can't put an @ in the local part ... even
 org.apache.james.core.Username#fromLocalPartWithoutDomain[1] won't bypass
 that ( and of course the usual not null, not empty)
 As you can see in
 
https://github.com/apache/james-project/blob/master/core/src/main/java/org/apache/james/core/Username.java#L132,
 a Username has a mapping to a org.apache.james.core.MailAddress and this
 mapping is used in multiple places. Allowing @ in the username would break
 that conversion.

 Can you provide a more detailed picture of what you are trying to achieve
 and why you would want @ as part of the username ? 



We're building a custom IMAP-server, based on JAMES, where users provide their 
IMAP-username on the format <username>@<customer-key>, where the username may 
be anything (except blank, ofcourse). The <customer-key> (provided as part of 
the USERNAME as far as JAMES/IMAP knows, parsed as "anything after the last 
'@'-character") is used for knowing which database-mapping to use. It seems 
JAMES is hardcoded to the concept of usernames being an email-address, or part 
of it, and that is not always the case for us/our users. In that sense it seems 
JAMES is intended for use as an application, not a library, is this correct? 

In other words; We need the username to be "whatever", and case-sensitive, so 
it would be preferable if Username was less restrictive, or an interface. 
Without this we'll have to base32-encode (because of case-insensitivity in 
Username) the username parsed with our custom LoginCommandParser, and decode 
where needed. 


Thanks. 


-- 
Andreas Joseph Krogh 
CTO / Partner - Visena AS 


(I'll admit that the current check is overly restrictive as it doesn't
 account for quoting in the local part [2] which allows using @ in a quoted
 string or escaping @ using a \)

 [1]
 
https://github.com/apache/james-project/blob/master/core/src/main/java/org/apache/james/core/Username.java#L71
 [2] https://datatracker.ietf.org/doc/html/rfc3696#section-3

 Cheers,
 Jean 
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to