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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
