Finally, we released the first version of dropwizard-pac4j :) See the announce on dropwizard-user https://groups.google.com/forum/#!topic/dropwizard-user/FAQrlkwFZ-g
Thanks Evan for all your help! Victor Le lundi 22 août 2016 10:57:36 UTC+2, victo...@gmail.com a écrit : > > Hi, > > FYI, I am currently trying to integrate pac4j with jersey filters (instead > of jetty's filters, for various reasons not of real interest here). > So this is another way how we could integrate pac4j with dropwizard I > think. > > I also agree with the idea of reusing something like pac4j instead of > having dropwizard implements its own authn/authz framework. > > Note though that I think pac4j still needs some improvement before it can > be considered as mature as jetty and jersey are: dropwizard is mature > because all of the libraries it integrates are themselves mature. > Nevertheless, I think pac4j is maybe more mature on some aspects that > dropwizard-auth (and that's why I stopped using the later for the former :). > > These are just some opinions on the discussion, I hope to be of help :) > > Le vendredi 12 août 2016 17:47:08 UTC+2, Jérôme LELEU a écrit : >> >> Hi, >> >> No problem. I just wanted to understand the reasons behind this >> "complexity". Indeed, power comes at a price and dropwizard-auth will >> always remain easier. >> >> j2e-pac4j is a powerful security library with many features but indeed, >> it's not easy to use it for Dropwizard at first glance: providing a thin >> layer of integration / configuration is a smart idea. >> >> I'm a bit surprised that you don't plan to use indirect clients (web >> applications) and only direct clients (REST API). Is Dropwizard (almost) >> only used for web services? But you know better, and it wouldn't be too >> much work to add indirect clients. >> >> Most technical discussions are meant to happen on the pac4j-dev mailing >> list: https://groups.google.com/forum/?fromgroups#!forum/pac4j-dev or at >> worst here >> >> Are external Dropwizard modules referenced somewhere? I plan to add a >> link to your module from the pac4j README page if you agree. In the future, >> we can even move your lib to the pac4j organization. >> >> Thanks. >> Best regards, >> Jérôme >> >> >> >> >> 2016-08-12 16:56 GMT+02:00 Evan Meagher <evan.m...@gmail.com>: >> >>> Hello Jérôme, thank you for reaching out. Right off the bat, I want to >>> apologize for my comment regarding pac4j's "complexity". I didn't mean it >>> as an indictment of you or your work. I was framing pac4j in relation to >>> libraries such as dropwizard-auth (or even moreso Moxie's >>> dropwizard-simpleauth), which opt to take a minimalist approach to auth >>> mechanism support. Libraries with as impressive a range of covered >>> functionality as pac4j will inevitably be "complex" in comparison, so my >>> statement was unfair. >>> >>> I'd be happy to continue work on dropwizard-pac4j, taking the >>> suggestions you made on pac4j-users@ >>> <https://groups.google.com/forum/#!topic/pac4j-users/Q_7eYrGFHaE> to >>> heart. I think a good first step would be to clarify a precise scope for >>> the library. There may be corners of pac4j that it doesn't make sense for >>> Dropwizard to support. As an attempt at this, I was planning to initially >>> write dropwizard-pac4j in such a way that it specifically targets REST API >>> servers rather than web applications, hence the support for SecurityFilter >>> alone. >>> >>> I think the best route for now is to continue to isolate the >>> Dropwizard+pac4j integration within a "bundle" (Dropwizard parlance for a >>> module). Dropwizard strives to be more of a collection of libraries than >>> what would normally be thought of as a "web framework". The most idiomatic >>> outcome would be to provide a library that can easily be integrated into >>> applications in place of dropwizard-auth. >>> >>> This discussion probably isn't within the scope of the dropwizard-dev >>> list anymore, since we're talking about a library outside of Dropwizard >>> itself. I don't see any mention of an IRC channel in pac4j's documentation, >>> so I'll shift the discussion back over to pac4j-users@ for now. >>> >>> On Fri, Aug 12, 2016 at 1:18 AM, Jérôme LELEU <lel...@gmail.com> wrote: >>> >>>> And of course, I'll be more than happy to help the Dropwizard team to >>>> integrate pac4j deeper in his auth framework (like I do for Jooby, >>>> Ratpack, >>>> CAS, Vertx, Knox...) >>>> >>>> >>>> >>>> >>>> On Friday, August 12, 2016 at 9:40:39 AM UTC+2, Jérôme LELEU wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm the creator of pac4j. My core goal is to make it really easy >>>>> (compared to Spring Security or other frameworks I know). >>>>> >>>>> Of course, it's a security engine working in a dozen of frameworks, so >>>>> there are downsides, but it should stay easy. There are two main >>>>> concepts: >>>>> clients for authentication and authorizers for authorizations and two >>>>> main >>>>> "filters": the "security filter" to protect urls and the "callback >>>>> filter" >>>>> to finish external login process. >>>>> >>>>> Reading "pac4j is immensely complex", I'd really like to get feedbacks >>>>> and understand what this complexity is. >>>>> >>>>> Thanks. >>>>> Best regards, >>>>> Jérôme >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wednesday, August 10, 2016 at 2:55:01 AM UTC+2, Evan Meagher wrote: >>>>>> >>>>>> After spending a bit more time on this, I can confirm Moxie's initial >>>>>> suspicions that pac4j is immensely complex. >>>>>> >>>>>> If anyone's curious, I've put together a bundle >>>>>> <https://github.com/evnm/dropwizard-pac4j> for integrating j2e-pac4j >>>>>> with Dropwizard to secure endpoints. >>>>>> >>>>>> On Sun, Jul 31, 2016 at 6:00 PM, Evan Meagher <evan.m...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Definitely don't disagree that pac4j seems complex. But >>>>>>> Hibernate/Logback/Jackson/etc are complex too. I think Dropwizard's >>>>>>> tenet >>>>>>> of simplicity stems from its saying "if you need to run a web service, >>>>>>> here >>>>>>> is the limited subset of functionality ofrom a few great libraries from >>>>>>> the >>>>>>> morass of wanton complication that is the Java ecosystem". I don't >>>>>>> think >>>>>>> it'd be out of tune to bite off a reasonable subset of pac4j for use as >>>>>>> an >>>>>>> entry point. >>>>>>> >>>>>>> Admittedly, most of the support requests that I alluded to fall into >>>>>>> the trap of "one person's API confusion is another's developer >>>>>>> laziness", >>>>>>> so I may be tilting at windmills. >>>>>>> >>>>>>> Here are a few examples: >>>>>>> >>>>>>> - Person asking about optionally protected endpoints: >>>>>>> >>>>>>> https://groups.google.com/forum/#!searchin/dropwizard-user/auth|sort:relevance/dropwizard-user/PrVzZev5mT4/Hx8u18q6AAAJ >>>>>>> - Authorization based on request parameters requires bending >>>>>>> over backwards: >>>>>>> >>>>>>> https://groups.google.com/forum/#!searchin/dropwizard-user/auth|sort:date/dropwizard-user/JosubiZPn5U/aRwuMDJNAgAJ >>>>>>> - Support for different auth regimes for different endpoints: >>>>>>> here <https://github.com/dropwizard/dropwizard/issues/1050>, here >>>>>>> <https://github.com/dropwizard/dropwizard/issues/1318>, and here >>>>>>> <https://github.com/dropwizard/dropwizard/issues/1579> >>>>>>> >>>>>>> Not knowing of dropwizard-simpleauth's existence, this last >>>>>>> painpoint prompted me to implement a separate suite of polymorphic >>>>>>> auth wiring >>>>>>> <https://github.com/dropwizard/dropwizard/commit/a469b208d71c579e2c0e06567431c4608bfe7b1a>, >>>>>>> >>>>>>> which is now in master. >>>>>>> >>>>>>> I agree that in principle a simpler auth package is ideal, but >>>>>>> there's a fine line between a clean library for "typical" use cases and >>>>>>> one >>>>>>> that is flexible enough to suit the majority of applications' needs. >>>>>>> The >>>>>>> development and support history of dropwizard-auth shows that its users >>>>>>> need it to be able to support many different configurations. >>>>>>> >>>>>>> With this in mind, a library like pac4j could be seen as the logical >>>>>>> conclusion of our continuing to add functionality piecemeal. If so, I >>>>>>> think >>>>>>> we could avoid a bunch of work and probably provide a more cohesive >>>>>>> solution overall if we offered an easy path to using pac4j. >>>>>>> >>>>>>> One solution could be to provide a "no configuration needed" library >>>>>>> (dropwizard-auth, or stripped down variant thereof) alongside an >>>>>>> alternative for those with advanced/finicky requirements (e.g. >>>>>>> dropwizard-pac4j). To me, the situation seems similar to that of >>>>>>> dropwizard-db and its two "implementations", dropwizard-jdbi and >>>>>>> dropwizard-hibernate. >>>>>>> >>>>>>> On Sun, Jul 31, 2016 at 4:57 PM, Moxie Marlinspike < >>>>>>> mo...@thoughtcrime.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 07/29/2016 04:40 PM, Evan Meagher wrote: >>>>>>>> > dropwizard-auth keeps coming up as a source of confusion and >>>>>>>> missing >>>>>>>> > functionality, both on GitHub and dropwizard-user@. It does most >>>>>>>> jobs >>>>>>>> > adequately, but requires developers to learn idiosyncrasies which >>>>>>>> are >>>>>>>> > arguably more a consequence of history than of purpose. If >>>>>>>> there's a >>>>>>>> > well-maintained and community-supported alternative available, >>>>>>>> then >>>>>>>> > perhaps it represents an opportunity to reduce the surface area >>>>>>>> of code >>>>>>>> > maintained by the Dropwizard community. >>>>>>>> >>>>>>>> What are the main sources of confusion and missing functionality >>>>>>>> that >>>>>>>> you've noticed people encounter with dropwizard-auth? Glancing at >>>>>>>> pac4j, it seems pretty complex! I feel like dropwizard's strength >>>>>>>> is >>>>>>>> its simplicity, and would actually prefer the default auth package >>>>>>>> to be >>>>>>>> even simpler, if it were up to me: >>>>>>>> >>>>>>>> https://github.com/whispersystems/dropwizard-simpleauth >>>>>>>> >>>>>>>> - moxie >>>>>>>> >>>>>>>> -- >>>>>>>> http://www.thoughtcrime.org >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "dropwizard-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to dropwizard-de...@googlegroups.com. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Evan Meagher >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Evan Meagher >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "dropwizard-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to dropwizard-de...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Evan Meagher >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "dropwizard-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to dropwizard-de...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "dropwizard-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
