Asf wiki is not the best place for brainstorming, as is usable only for people w asf accounts (i guess).
What if we create a repo like "maven-rfc", where anyone can raise PRs (new functionality, change requests or just ideas), these would be like "proposals", that we discuss and modify specs w PRs, and once proposal considered "complete", it can be moved to "to be implemented" state (those could be plain directories), maybe even version those things? And then implementation can happen based on documented requirements/functionality? T On Wed, Jun 5, 2024, 20:27 Tamás Cservenák <ta...@cservenak.net> wrote: > Howdy, > > Bernd, I would be very interested to collect some ideas to solve exactly > this problem... > When I revamped maven-gpg-plugin re "worst practices", I started tinkering > about this... > > Created page just to gather ideas... > > https://cwiki.apache.org/confluence/display/MAVEN/Handling+sensitive+data+in+Maven > > Unsure is this editable for you... we may want some other place for > brainstorming? > > Thanks > T > > On Wed, Jun 5, 2024 at 7:24 PM Bernd Eckenfels <e...@zusammenkunft.net> > wrote: > >> BTW Speaking of “custom”, I would be very interested in >> a token based authentication, at least for read access to >> our repository server and mirror, we currently ship a static >> read-only login, and also we don’t want to allow putting >> their write (LDAP Login) credentials into files. >> >> If the maven ecosystem would have a OS/Token method >> like requestin a JWT token from a distribution point which >> uses native Kerberos SSPI or user certificates that would >> greatly improve this, >> >> What’s your plan for that auth, can you upstream it? >> >> Gruß >> Bernd >> >> David Grieve wrote on 4. June 2024 20:33 (GMT +02:00): >> >> > Thank you for the hint, Tamás. >> > >> > The problem I’m trying to solve is that I want a custom Authentication >> > for a particular server. I do not want to re-implement HttpTransporter. >> > Here are the important bits of what I’ve come up with. >> > ---------------------------------- >> > public class MyTransporterFactory implements TransporterFactory { >> > >> > // copied from >> > org.eclipse.aether.transport.http.HttpTransporterFactory >> > private static Map<String, ChecksumExtractor> >> > getManuallyCreatedExtractors() { >> > HashMap<String, ChecksumExtractor> map = new HashMap<>(); >> > map.put(Nexus2ChecksumExtractor.NAME, new >> > Nexus2ChecksumExtractor()); >> > map.put(XChecksumChecksumExtractor.NAME, new >> > XChecksumChecksumExtractor()); >> > return Collections.unmodifiableMap(map); >> > } >> > >> > // I’m not happy with this... >> > private final HttpTransporterFactory httpTransporterFactory = new >> > HttpTransporterFactory(getManuallyCreatedExtractors()); >> > >> > @Override >> > public Transporter newInstance(RepositorySystemSession session, >> > RemoteRepository repository) throws NoTransporterException { >> > >> > if (requiresSpecialAuth(repository)) { >> > repository = new RemoteRepository.Builder(repository) >> > .setAuthentication(new MyAuthentication(repository)) >> > .build(); >> > } >> > return httpTransporterFactory.newInstance(session, repository); >> > } >> > ---------------------------------- >> > >> > Then “MyAuthentication” does the right thing for the fill method. >> > >> > This approach is working for me, but I’d be interested to know if there >> > is a better way. I do not want to re-implement HttpTransport! >> > >> > >> > On 2024/06/03 20:25:48 Tamás Cservenák wrote: >> >> Howdy, >> >> >> >> What are you trying to do? You may go better if you implement custom >> >> (resolver) transport maybe? >> — >> https://bernd.eckenfels.net >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >>
