Hello Andreas,

On 08/06/2021 21:56, Andreas Joseph Krogh wrote:
> 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.
>  
I do not get why you need to rely on the Username POJO in your custom
IMAP stack.

Maybe you can introduce some abstractions that suites your needs and
have the logic to convert it to the James POJOs in places that are needed.

Also turning off virtual hosting enables to pass any string (except `@`)
in the local part. Maybe this could be sufficient to easily solve your
issue?

Benoit
> --
> *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