Forgot to respond to your last paragraph, great to hear that you're open to make Username protected, we'll make a PR.
Den 10. juni 2021 15:44:17 CEST, skrev "btell...@apache.org" <btell...@apache.org>: > >On 10/06/2021 18:43, Andreas Joseph Krogh wrote: >> På torsdag 10. juni 2021 kl. 05:09:50, skrev btell...@apache.org >> <mailto:btell...@apache.org> <btell...@apache.org >> <mailto:btell...@apache.org>>: >> >> [...] >> > 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. >> >> >> >> Username is not really a POJO, by definition, as it does lots more >> than just holding on to the "iserid". I agree that having a >> Username-type is cool for type-safety, but it should only wrap the >> "userid"-String, nothing else. >> >> >> >> >> > - 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. >> >> >> >> We only use JAMES for IMAP. > >So you only use the content of /protocols/imap, correct? > >This means that you had been implementing / will be implementing some >mailbox-api implementation of your own, correct? > >> >> >> > - 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. >> [...] >> > 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. >> >> >> >> Do you mean "we can, as of James-3.6" or in "som future version".I >> don't understand how we could accomplish that in v-3.6 due to the >> limitations of the Username-type, which I'm describing in this thread, >> and that Username is used "all over" in the IMAP-API. It's an integral >> part of UserRepository and lots of other classes mentioned in previous >> emails, so it's impossible to implement an IMAP-server using >> James-3.6-API without using it, unless I'm missing something. >> >> >> >> >> Turning off virtual-hosting will also remove the limitation of the >> domains that as I understand is the point limiting you. >> >> >> >> The only thing which is limiting us is that Username is enforcing >> constraints not specified by the IMAP-standard for "userid". We don't >> use virtual-hosting or other JAMES-stuff, only the IMAP-stack for >> being able to act as an IMAP-server. We have implemented custom stuff >> to retrieve/store data in our custom-modelled database, and everything >> works well in that regards. > >@Test void arbitraryCharInLocalPart() { > assertThatCode(() -> Username.of("Whatever_I- want3$$$###_! as lons I do > not give a domain")) > .doesNotThrowAnyException(); } > > >The only constraint if a domain part is unspecified, is the size of 256 >character and the absence of @. > > >To come back to your original problem, what prevents, for instance the >user scheme to be: <username>_<customer-key> ? > >> >> As I've mentioned earlier, we get around this by using Base32-encoding >> for the "localPart" in Username and decode it wherever we need the >> value, but we'd really like the restrictions enforced by it to be >> removed, to comply with the IMAP-standard. > >The truth is that the IMAP stack is not independant of the James server >and as such, in another thread propose to move it back into >server/protocols folder to make this clear. While generifying the IMAP >code is noble, we will end up finding out that Username usage is >enforced at mailbox-api usage and we start getting quite inside James guts. > >That being said, I think having more generic CommandParsers (that can >thus be used outside of James context) and modular IMAP Processor/ >command processor would allow for greater power for people reusing this >code. This should allow people to choose precisely which part of the >IMAP stack they wish to use. > >Regarding your immediate problem, I personally no problems having >Username protected to allow one to subclass it if need be. Likely this >is the simplest option here. Feel free to open a pull request. > >Regards, > >Benoit > > >> >> Thanks. >> >> -- >> *Andreas Joseph Krogh* >> CTO / Partner - Visena AS >> Mobile: +47 909 56 963 >> andr...@visena.com <mailto:andr...@visena.com> >> www.visena.com <https://www.visena.com> >> <https://www.visena.com> >>
