Yes, +1 for OAuth support! regards,
François [email protected] Le 05/04/2020 à 15:11, Brian Demers a écrit : > OAuth support has been on the top of my list for a while too! We added > a bearer token filter in 1.5, but that is only part of the way there > for just one flow. > > Anything specific you are looking for? Resource Server? A standard > redirect (auth code flow)? OIDC support? etc > > -Brian > >> On Apr 5, 2020, at 7:59 AM, Rob Young <[email protected]> wrote: >> >> >> Our org uses pac4j for doing oauth and I'd love to drop it, it's one >> too many security libraries. It would be fantastic if shiro could >> provide this natively. >> >> On Sun, Apr 5, 2020 at 7:47 AM Richard Adams >> <[email protected] <mailto:[email protected]>> wrote: >> >> I don't know if this is out of scope, or has been talked about >> already, but providing some boiler-plate, best-practice standard >> OAuth2 flows would be good, either for a client getting tokens, >> or an authorisation server generating tokens. We've been >> implementing this sort of thing quite a bit ourselves lately, we >> are no experts but there surely is a need not to reinvent the >> wheel every time >>> On 05 April 2020 at 12:32 Brian Demers <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> This one? >>> >>> >>> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md >>> >>> >>> -Brian >>> >>>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> I wrote a whole wiki page on 2.0 design changes, but I can't >>>> find it now 🤔 >>>> >>>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers < >>>> [email protected] <mailto:[email protected]>> wrote: >>>> >>>> +1 >>>> >>>> Off the top of my head we have (I'm sure there is more, but ): >>>> >>>> * Package name / artifact structure cleanup (breaking >>>> change, but minor impact) >>>> * Remove CAS modules >>>> * Replace deprecated code (or move to an >>>> implementation/private package, for anything still needed) >>>> * Support javax.annotation.security annotations (or >>>> whatever they are now under Eclipse). These annotations >>>> work a little different from the Shiro ones. >>>> >>>> * Update to Jakarta dependencies (or figure out a way to >>>> work with both, abstracting the HTTP logic), bigger lift >>>> (or maybe two different 'web' packages?) >>>> >>>> The Jakarta ones have me a little worried though, I think >>>> many of the current Shiro users would have a hard time >>>> making the switch anytime soon. Which could kill the >>>> adoption of a 2.0. >>>> We could (and probably should) abstract the web specifics >>>> out in order to support the _current_ API, Jakarta EE, and >>>> other non-servlet stacks (reactive). >>>> That said, it's a likely a bunch of work (and again, I'm >>>> guessing most of the user base would use the current API), >>>> so this _could_ be a 3.0 item. >>>> >>>> Thoughts? >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < >>>> [email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>> I would like to start a thread about the next major release: >>>> 2.0.0. >>>> I think we should move forward on it and only fix bug on the >>>> 1.x branches. >>>> >>>> There is always some issues related to the version in Jira: >>>> >>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455 >>>> >>>> We can move also the issues list from the 1.6.0 to the 2.0.0: >>>> >>>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916 >>>> >>>> I noticed an existing branch about api changes on github: >>>> >>>> https://github.com/apache/shiro/tree/2.0-api-design-changes >>>> >>>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x >>>> branch (from tag shiro-root-1.5.2) for maintenance. >>>> >>>> Because of some api break, package refactor, deprecated >>>> modules or components, we also should start a migration guide in the >>>> website. >>>> >>>> It's also time for anyone to bring some ideas about the next >>>> Shiro features/improvements, feel free to share :) >>>> >>>> We could start a formal vote to validate the plan. >>>> >>>> Feedback are welcome! >>>> >>>> regards, >>>> >>>> -- >>>> François >>>> [email protected] <mailto:[email protected]> >>>> >> >> >> >> >> >> -- >> Rob Young >> [email protected] <mailto:[email protected]> >>
