Cool! This isn’t my specialty so I might get the terms wrong. For me I think it’s the redirect authentication that I’m looking for. Basically you implement a web application and want to let users log in via an oauth service like google.
On Sunday, April 5, 2020, Brian Demers <brian.dem...@gmail.com> wrote: > 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 <bobbot...@gmail.com> 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 <rich...@researchspace.com> > 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 <brian.dem...@gmail.com> 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 <lhazlew...@apache.org> 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 < brian.dem...@gmail.com> >> 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 < >> francois.pa...@openobject.fr> 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çoisfpa...@apache.org >> >> >> >> > > > -- > Rob Young > robertjohnyo...@gmail.com > > -- Rob Young robertjohnyo...@gmail.com
