On 09/06/2021 19:45, Andreas Joseph Krogh wrote: > På onsdag 09. juni 2021 kl. 06:07:46, skrev btell...@apache.org > <mailto:btell...@apache.org> <btell...@apache.org > <mailto:btell...@apache.org>>: > > Hello Andreas, > [...] > 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? > > > > The reason we "have to" rely on Username is, AFAIU, that that's the > type being used by many classes which make up much of the login- and > other user-related code. We're thinking about > replacing LoginCommandParser, but the Username-class is what's being > passed around so I don't see any way around having to rely on it. Am I > missing something? > > There are several things I find strange about the current logic in, > and usages of, Username: > > 1. The login-parser should do just that parse the login-command and > provide the Strings /as //is/, not try to do anything meaningful og > enforce constraints on it, as Username does. Having login-parser agnostic of James internal logic would seem like a fair point to me, I can agree with that.
(We could introduce a new POJO that do not enforce constraints in order to preverve strong typing.) > > 2. The logic in Username seems flawed: > - Why a limit on length? Nothing in the protocol dictates this. James has to be working with several protocols, not just IMAP. Implementation details (JPA) might have been pushing these kind of concerns to the Username POJO. > - The username used for IMAP-LOGIN is completely decoupled from > whatever <local-part> is in an email-address. Yes, they /could/ be > related but are often not, even if modern MUAs like to think so. > Username should make no asumptions about local-part/domain-part in the > provider userid. Here likely lies the root cause: contrary to (say) SMTP, IMAP so far is hard coupled with the James implementation, with hard dependencies on things like mailbox-api. > - According to the spec the LOGIN-command is: > login = "LOGIN" SP userid SP password > userid = astring > astring = 1*ASTRING-CHAR / string > string = quoted / literal > > So any string will be valid for "userid", and it's up to the site > (where the IMAP-server is used) to interpret the userid case-sensitive > or insensitive, so JAMES show not enforce anything and just "leave it > as is". I understand that James is free to do whatever it wants with userId validation. I understand that tooling is missing to allow people to override that behaviour in James / James IMAP stack. > > > We're getting around this by base32-encoding the username before > constructing the Username-object, and decoding it where we use it for > retreiving our custom User-objects, which we stuff in the ImapSession. > > Username is used/leaking in many places (e.g. UserRepository, > MailboxSession), which whould be fine if the Username-class didn't > enforce any rules on "userid", so as it is now we have no choise to > not rely on it. > > So - I'm proposing to refactor so that Username only wraps the parsed > "userid"-String, nothing else. If validation or other stuff is needed > I think that should be handled by some other /interface/ which the > JAMES-project is free to provide a default-impl of, but it must be > possible to implement custom logic. Also proposing to pull out all the > from*-factory-methods. > > What do you think? Personally I am reluctant to weaken data validation , that is already reasonably permissive, without understanding the impacts on the code base. I do think that there is other alternatives than hard-coding logic into usernames. You could rely on custom API / classes to make the bridge between usernames and your custom logic. Turning off virtual-hosting will also remove the limitation of the domains that as I understand is the point limiting you. Cheers, Benoit > -- > *Andreas Joseph Krogh* > CTO / Partner - Visena AS >
