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 Stringsas is, not try to do anything meaningful og enforce constraints on it, as Username does. 2. The logic in Username seems flawed: - Why a limit on length? Nothing in the protocol dictates this. - The username used for IMAP-LOGIN is completely decoupled from whatever <local-part> is in an email-address. Yes, theycould 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. - 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". 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 otherinterface 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? -- Andreas Joseph Krogh CTO / Partner - Visena AS
--------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
