You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Francois Papon <fr...@openobject.fr> on 2020/04/04 12:29:33 UTC
[DISCUSS] - Move to 2.0.0
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
fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
Armadno,
I'm saying you could get access to a set of common data for a given user,
which is fine for many apps, but it doesn't replace an
application-specific user store for other use cases (for example complex
user preferences).
Shiro could make it easier to associate arbitrary attributes (or a user
type) to help with these use cases. Maybe something like
`Subject.getAttribute("givenName")`
Thoughts?
On Mon, Apr 6, 2020 at 7:17 AM armandoxxx <ar...@dropchop.com> wrote:
> I'm not sure that I completly understand this ..
>
> but all user details can be put into Subject in realm and everything can be
> taken out later on from that subject (this is what we do) ...
> Would like to understand more about this if you could explain it. Thank you
> !
>
> Regards
>
> Armadno
>
>
>
> --
> Sent from: http://shiro-user.582556.n2.nabble.com/
>
Re: [DISCUSS] - Move to 2.0.0
Posted by armandoxxx <ar...@dropchop.com>.
I'm not sure that I completly understand this ..
but all user details can be put into Subject in realm and everything can be
taken out later on from that subject (this is what we do) ...
Would like to understand more about this if you could explain it. Thank you
!
Regards
Armadno
--
Sent from: http://shiro-user.582556.n2.nabble.com/
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
Great point, often a realm would have access to this information from the
same query when authenticating.
Shiro wouldn't be able to replace a general user details store, but we
should think about making it easier to expose it out of the box (without
implementing a custom realm and principal type)
On Sun, Apr 5, 2020 at 1:52 PM Bart van Leeuwen <ba...@netage.nl>
wrote:
> Hi all,
>
> this might be a RTFM related remark or me missing the concepts,
> One of the issues I've always been struggling with is the use of in LDAP
> terms 'Common Names'
> I'm able to use LDAP to authenticate and authorize a user, but I can't get
> a common name to use in UI's or data recording.
>
> Which results in accessing LDAP myself to get these details which almost
> defies the use of Shiro
>
> Otherwise I love the library!
>
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen
>
>
> twitter: @semanticfire
> tel. +31(0)6-53182997
> Netage B.V.
> http://netage.nl
> Esdoornstraat 3
> 3461ER Linschoten
> The Netherlands
>
>
>
>
> From: Francois Papon <fr...@openobject.fr>
> To: dev@shiro.apache.org
> Cc: user@shiro.apache.org
> Date: 04-04-2020 14:29
> Subject: [DISCUSS] - Move to 2.0.0
> ------------------------------
>
>
>
> 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*
> <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*
> <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*
> <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
> *fpapon@apache.org* <fp...@apache.org>
>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Bart van Leeuwen <ba...@netage.nl>.
Hi all,
this might be a RTFM related remark or me missing the concepts,
One of the issues I've always been struggling with is the use of in LDAP
terms 'Common Names'
I'm able to use LDAP to authenticate and authorize a user, but I can't get
a common name to use in UI's or data recording.
Which results in accessing LDAP myself to get these details which almost
defies the use of Shiro
Otherwise I love the library!
Met Vriendelijke Groet / With Kind Regards
Bart van Leeuwen
twitter: @semanticfire
tel. +31(0)6-53182997
Netage B.V.
http://netage.nl
Esdoornstraat 3
3461ER Linschoten
The Netherlands
From: Francois Papon <fr...@openobject.fr>
To: dev@shiro.apache.org
Cc: user@shiro.apache.org
Date: 04-04-2020 14:29
Subject: [DISCUSS] - Move to 2.0.0
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
fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
Agreed Sreenivas,
Do you have a list of specific features you are looking for so we can try
to prioritize them?
On Mon, Apr 6, 2020 at 3:56 AM sreenivas harshith <sr...@yahoo.com>
wrote:
> Hi,
>
> Provide native Integrations of pac4j with shiro, jwt , oauth, feature
> parity with other security frameworks like spring , spring security and
> others in the .net c# world.
>
>
>
>
>
> On Mon, Apr 6, 2020 at 12:23 PM +0530, "Benjamin Marwell" <
> bmarwell@gmail.com> wrote:
>
> I want to throw in JSON web tokens (JWT).
>>
>> It is a mess to work with them right now.
>>
>> JWT can also be very complicated. They can only hold Authentication data,
>> or they can hold roles, or even permission (if it is not getting too long).
>> I settled to create another realm. If the JWT contains EVERYTHING, the
>> other realms must be skipped (that's the whole point). If it does only
>> contain authc, there must be a possibility to search either the other
>> realms or a special authz-only-realm. The latter is not possible atm
>> because AuthorizingRealms extend AuthenticatingRealm.
>>
>> It is not hard to create a JWT Authc realm, though. As the Token class is
>> different, login will just skip the JWT realm.
>>
>> … and there is so much more to it!
>>
>>
>> Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <
>> jb@nanthrax.net>:
>>
>>> Yeah, it seems to be the same indeed.
>>>
>>> Regards
>>> JB
>>>
>>> > Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr>
>>> a écrit :
>>> >
>>> > I found this one:
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>>> >
>>> > It seems to be the same :)
>>> >
>>> > regards,
>>> >
>>> > François
>>> > fpapon@apache.org
>>> >
>>> > Le 05/04/2020 à 13:32, Brian Demers a écrit :
>>> >> 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 <lh...@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 <br...@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.papon@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çois
>>> >>>>> fpapon@apache.org
>>>
>>>
Re: [DISCUSS] - Move to 2.0.0
Posted by sreenivas harshith <sr...@yahoo.com>.
Hi,
Provide native Integrations of pac4j with shiro, jwt , oauth, feature parity with other security frameworks like spring , spring security and others in the .net c# world.
On Mon, Apr 6, 2020 at 12:23 PM +0530, "Benjamin Marwell" <bm...@gmail.com> wrote:
I want to throw in JSON web tokens (JWT).
It is a mess to work with them right now.
JWT can also be very complicated. They can only hold Authentication data, or they can hold roles, or even permission (if it is not getting too long).I settled to create another realm. If the JWT contains EVERYTHING, the other realms must be skipped (that's the whole point). If it does only contain authc, there must be a possibility to search either the other realms or a special authz-only-realm. The latter is not possible atm because AuthorizingRealms extend AuthenticatingRealm.
It is not hard to create a JWT Authc realm, though. As the Token class is different, login will just skip the JWT realm.
… and there is so much more to it!
Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <jb...@nanthrax.net>:
Yeah, it seems to be the same indeed.
Regards
JB
> Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> fpapon@apache.org
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> 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 <lh...@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 <br...@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 <fr...@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çois
>>>>> fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Benjamin Marwell <bm...@gmail.com>.
Hi Brian,
yes, I totally meant VALIDATING a JWT. Absolutely. Not issuing one. That is
easy enough for users to implement it theirselves.
JWTs only make sense if they are used:
1. stateless, i.e. no session
2. not as a cookie replacement
3. not as a authz replacement (it should most of the times only carry small
authc data)
That said, if a user comes with a bearer token, shiro bears two challenges:
1.) The jwt can easily be validated in the realm, just implement
doGetAuthenticationInfo and check issuer, date and signature. That's easy.
2.) If you need to extract authz data, well that's a different problem. if
you hit that method, you do not have the key in hand - just look at the
method signature:
protected AuthorizationInfo doGetAuthorizationInfo(final
PrincipalCollection principals)
So you need to store it in a small cache, which does not feel right. Or
just look up everything from a 3rd datasource, like your DB. But then, you
can just skip this Realm for the Authc part and have a more general authc
strategy.
That said, for multiple realms, just imagine this:
1. Authc via JWT
2. Authc via LDAP
3. Authc via static config file
But for all three realms you want to look up your own database for
authorization. You need to implement your own delegator. And I think it is
not easy to understand this as a shiro newbie.
Am Mo., 6. Apr. 2020 um 16:26 Uhr schrieb Brian Demers <
brian.demers@gmail.com>:
>
> There are a couple of different items in one
>
> 1.) using JWTs to hold authentication data.
> How are you minting the original token? are you getting it from a request
> header (i.e. bearer token)
>
> Thoughts (possibly unrelated) Shiro probably should support some sort of
> JWT bearer token out of the box similar to support OAuth IdPs that use JWT
> for access tokens. (the tricky thing is there is no spec around this so
> each vendor could be doing something slightly different)
>
> 2.) Authorizing vs Authenticating realms
> While this is possible today it probably isn't as easy or as obvious as it
> could be.
> As you mentioned the AuthZ realm extends the AuthC realm. Right now you
> can probably do this by creating a custom auth strategy +
> ModularRealmAuthorizor.
> Maybe adding an AuthZ strategy to the ModularRealmAuthorizor would help
> here? (and providing default implementations so this could be configured
> with minimal effort)
>
> 3.) JWT Authc realm.
> I'm really hesitant on making Shiro mint JWTs (except maybe in the case of
> the RemembeMeManager). As you mentioned there is a lot around JWTs that
> need to be considered:
> https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
>
> But if you are talking about OAuth2 Resource Server use cases (where Shiro
> would be validating an JWT), I do think that should be on the table.
>
>
> You also bring up the point about getting everything out of the
> authentication token (authz info as well), this is possible today, but
> again it is less obvious how to do it, and this is NOT an uncommon use case.
> This is related to another comment about getting at other attributes from
> a user. Maybe a Shiro Subject/PrincipalCollection should hold a set of
> attributes?
>
> ```
> Subject.getAttribute("givenName") == "Brian
> ```
>
> (something similar could be used when building a set of roles:
>
> ```
> principalCollection.get("groups")
> ```
>
> Thoughts?
>
>
> On Mon, Apr 6, 2020 at 2:53 AM Benjamin Marwell <bm...@gmail.com>
> wrote:
>
>> I want to throw in JSON web tokens (JWT).
>>
>> It is a mess to work with them right now.
>>
>> JWT can also be very complicated. They can only hold Authentication data,
>> or they can hold roles, or even permission (if it is not getting too long).
>> I settled to create another realm. If the JWT contains EVERYTHING, the
>> other realms must be skipped (that's the whole point). If it does only
>> contain authc, there must be a possibility to search either the other
>> realms or a special authz-only-realm. The latter is not possible atm
>> because AuthorizingRealms extend AuthenticatingRealm.
>>
>> It is not hard to create a JWT Authc realm, though. As the Token class is
>> different, login will just skip the JWT realm.
>>
>> … and there is so much more to it!
>>
>>
>> Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <
>> jb@nanthrax.net>:
>>
>>> Yeah, it seems to be the same indeed.
>>>
>>> Regards
>>> JB
>>>
>>> > Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr>
>>> a écrit :
>>> >
>>> > I found this one:
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>>> >
>>> > It seems to be the same :)
>>> >
>>> > regards,
>>> >
>>> > François
>>> > fpapon@apache.org
>>> >
>>> > Le 05/04/2020 à 13:32, Brian Demers a écrit :
>>> >> 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 <lh...@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 <br...@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.papon@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çois
>>> >>>>> fpapon@apache.org
>>>
>>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
There are a couple of different items in one
1.) using JWTs to hold authentication data.
How are you minting the original token? are you getting it from a request
header (i.e. bearer token)
Thoughts (possibly unrelated) Shiro probably should support some sort of
JWT bearer token out of the box similar to support OAuth IdPs that use JWT
for access tokens. (the tricky thing is there is no spec around this so
each vendor could be doing something slightly different)
2.) Authorizing vs Authenticating realms
While this is possible today it probably isn't as easy or as obvious as it
could be.
As you mentioned the AuthZ realm extends the AuthC realm. Right now you
can probably do this by creating a custom auth strategy +
ModularRealmAuthorizor.
Maybe adding an AuthZ strategy to the ModularRealmAuthorizor would help
here? (and providing default implementations so this could be configured
with minimal effort)
3.) JWT Authc realm.
I'm really hesitant on making Shiro mint JWTs (except maybe in the case of
the RemembeMeManager). As you mentioned there is a lot around JWTs that
need to be considered:
https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
But if you are talking about OAuth2 Resource Server use cases (where Shiro
would be validating an JWT), I do think that should be on the table.
You also bring up the point about getting everything out of the
authentication token (authz info as well), this is possible today, but
again it is less obvious how to do it, and this is NOT an uncommon use case.
This is related to another comment about getting at other attributes from a
user. Maybe a Shiro Subject/PrincipalCollection should hold a set of
attributes?
```
Subject.getAttribute("givenName") == "Brian
```
(something similar could be used when building a set of roles:
```
principalCollection.get("groups")
```
Thoughts?
On Mon, Apr 6, 2020 at 2:53 AM Benjamin Marwell <bm...@gmail.com> wrote:
> I want to throw in JSON web tokens (JWT).
>
> It is a mess to work with them right now.
>
> JWT can also be very complicated. They can only hold Authentication data,
> or they can hold roles, or even permission (if it is not getting too long).
> I settled to create another realm. If the JWT contains EVERYTHING, the
> other realms must be skipped (that's the whole point). If it does only
> contain authc, there must be a possibility to search either the other
> realms or a special authz-only-realm. The latter is not possible atm
> because AuthorizingRealms extend AuthenticatingRealm.
>
> It is not hard to create a JWT Authc realm, though. As the Token class is
> different, login will just skip the JWT realm.
>
> … and there is so much more to it!
>
>
> Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <
> jb@nanthrax.net>:
>
>> Yeah, it seems to be the same indeed.
>>
>> Regards
>> JB
>>
>> > Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr>
>> a écrit :
>> >
>> > I found this one:
>> >
>> >
>> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>> >
>> > It seems to be the same :)
>> >
>> > regards,
>> >
>> > François
>> > fpapon@apache.org
>> >
>> > Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> >> 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 <lh...@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 <br...@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.papon@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çois
>> >>>>> fpapon@apache.org
>>
>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Benjamin Marwell <bm...@gmail.com>.
I want to throw in JSON web tokens (JWT).
It is a mess to work with them right now.
JWT can also be very complicated. They can only hold Authentication data,
or they can hold roles, or even permission (if it is not getting too long).
I settled to create another realm. If the JWT contains EVERYTHING, the
other realms must be skipped (that's the whole point). If it does only
contain authc, there must be a possibility to search either the other
realms or a special authz-only-realm. The latter is not possible atm
because AuthorizingRealms extend AuthenticatingRealm.
It is not hard to create a JWT Authc realm, though. As the Token class is
different, login will just skip the JWT realm.
… and there is so much more to it!
Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <
jb@nanthrax.net>:
> Yeah, it seems to be the same indeed.
>
> Regards
> JB
>
> > Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr> a
> écrit :
> >
> > I found this one:
> >
> >
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
> >
> > It seems to be the same :)
> >
> > regards,
> >
> > François
> > fpapon@apache.org
> >
> > Le 05/04/2020 à 13:32, Brian Demers a écrit :
> >> 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 <lh...@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 <br...@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.papon@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çois
> >>>>> fpapon@apache.org
>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Benjamin Marwell <bm...@gmail.com>.
I want to throw in JSON web tokens (JWT).
It is a mess to work with them right now.
JWT can also be very complicated. They can only hold Authentication data,
or they can hold roles, or even permission (if it is not getting too long).
I settled to create another realm. If the JWT contains EVERYTHING, the
other realms must be skipped (that's the whole point). If it does only
contain authc, there must be a possibility to search either the other
realms or a special authz-only-realm. The latter is not possible atm
because AuthorizingRealms extend AuthenticatingRealm.
It is not hard to create a JWT Authc realm, though. As the Token class is
different, login will just skip the JWT realm.
… and there is so much more to it!
Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <
jb@nanthrax.net>:
> Yeah, it seems to be the same indeed.
>
> Regards
> JB
>
> > Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr> a
> écrit :
> >
> > I found this one:
> >
> >
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
> >
> > It seems to be the same :)
> >
> > regards,
> >
> > François
> > fpapon@apache.org
> >
> > Le 05/04/2020 à 13:32, Brian Demers a écrit :
> >> 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 <lh...@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 <br...@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.papon@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çois
> >>>>> fpapon@apache.org
>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Yeah, it seems to be the same indeed.
Regards
JB
> Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> fpapon@apache.org
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> 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 <lh...@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 <br...@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 <fr...@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çois
>>>>> fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Yeah, it seems to be the same indeed.
Regards
JB
> Le 5 avr. 2020 à 13:38, Francois Papon <fr...@openobject.fr> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> fpapon@apache.org
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> 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 <lh...@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 <br...@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 <fr...@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çois
>>>>> fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Francois Papon <fr...@openobject.fr>.
I found this one:
https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
It seems to be the same :)
regards,
François
fpapon@apache.org
Le 05/04/2020 à 13:32, Brian Demers a écrit :
> 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 <lh...@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 <br...@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 <fr...@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çois
>>>> fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Francois Papon <fr...@openobject.fr>.
I found this one:
https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
It seems to be the same :)
regards,
François
fpapon@apache.org
Le 05/04/2020 à 13:32, Brian Demers a écrit :
> 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 <lh...@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 <br...@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 <fr...@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çois
>>>> fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
Benjamin,
No worries we are on the same page :)
I absolutely agree with the cache issue between authc and authz. I've had
to work around that a couple times.
On Mon, Apr 6, 2020 at 10:42 AM Benjamin Marwell <bm...@gmail.com> wrote:
> Agreed, no oauth server - I was just talking about validating bearer
> tokens anyway. Didn't mention this, though. Sorry.
>
> Am Mo., 6. Apr. 2020 um 16:40 Uhr schrieb Brian Demers <
> brian.demers@gmail.com>:
>
>> Personally I don't think Shiro should implement an Authorization Server,
>> I think there is room for another project to implement on using Shiro (and
>> Shiro would likely benefit from this). This is actually a major
>> undertaking. The Spring Security folks tried to drop support for this
>> recently:
>> https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update IIRC,
>> they are still supporting this use case though.
>>
>> I have a bias opinion on this topic, so someone else please chime in. In
>> most cases, you probably wouldn't want to run your own
>> authorization server, but instead, use a different one KeyCloak if you want
>> to run it yourself, Okta, Microsoft, Google, etc if you don't.
>>
>> I could be in the minority here, what do others think?
>>
>>
>>
>> On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <ri...@researchspace.com>
>> wrote:
>>
>>> A framework or implementation of standard authorisation server endpoints
>>> such as /oauth/token for
>>> standard grant types such as refresh_token, password, authorisation_code
>>> etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
>>> <https://aaronparecki.com/oauth-2-simplified/#authorization>
>>> Could be a servlet filter, but if so should delegate to a handler which
>>> can be used in other places e.g. Spring Interceptors, Controllers,
>>> standalone applications etc. The Shiro approach of a standard
>>> out-of-the-box implementation with lots of configurable /overridable
>>> functionality would work well here, along with reference classes for the
>>> various types of token.
>>> E.g. anyone returning JSON of an OAuth token probably has a class
>>> similar to this, simple enough but why reinvent the wheel every time.
>>>
>>>
>>>
>>> /**
>>> * Represents the JSON response returned when refreshing / adding a new
>>> OAuth token
>>> */
>>> @Data
>>> *public* *class* NewOAuthTokenResponse {
>>>
>>> @JsonProperty("access_token")
>>> *private* String accessToken;
>>>
>>> @JsonProperty("refresh_token")
>>> *private* String refreshToken;
>>>
>>> @JsonIgnore
>>> *private* Instant expiryTime;
>>> *private* String scope;
>>>
>>> @JsonProperty("token_type")
>>> *private* *static* String *TOKEN_TYPE* = "bearer";
>>>
>>> @JsonProperty("expires_in")
>>> *public* Long expiresIn() {
>>> *return* Duration. *between*(Instant. *now*(),
>>> expiryTime).getSeconds();
>>> }
>>>
>>> }
>>>
>>>
>>> On 05 April 2020 at 14:11 Brian Demers <br...@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 <bo...@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 < richard@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.demers@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 < lhazlewood@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.demers@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.papon@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çoisfpapon@apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Rob Young
>>> robertjohnyoung@gmail.com
>>>
>>>
>>>
>>>
>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Benjamin Marwell <bm...@gmail.com>.
Agreed, no oauth server - I was just talking about validating bearer tokens
anyway. Didn't mention this, though. Sorry.
Am Mo., 6. Apr. 2020 um 16:40 Uhr schrieb Brian Demers <
brian.demers@gmail.com>:
> Personally I don't think Shiro should implement an Authorization Server,
> I think there is room for another project to implement on using Shiro (and
> Shiro would likely benefit from this). This is actually a major
> undertaking. The Spring Security folks tried to drop support for this
> recently:
> https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update IIRC,
> they are still supporting this use case though.
>
> I have a bias opinion on this topic, so someone else please chime in. In
> most cases, you probably wouldn't want to run your own
> authorization server, but instead, use a different one KeyCloak if you want
> to run it yourself, Okta, Microsoft, Google, etc if you don't.
>
> I could be in the minority here, what do others think?
>
>
>
> On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <ri...@researchspace.com>
> wrote:
>
>> A framework or implementation of standard authorisation server endpoints
>> such as /oauth/token for
>> standard grant types such as refresh_token, password, authorisation_code
>> etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
>> <https://aaronparecki.com/oauth-2-simplified/#authorization>
>> Could be a servlet filter, but if so should delegate to a handler which
>> can be used in other places e.g. Spring Interceptors, Controllers,
>> standalone applications etc. The Shiro approach of a standard
>> out-of-the-box implementation with lots of configurable /overridable
>> functionality would work well here, along with reference classes for the
>> various types of token.
>> E.g. anyone returning JSON of an OAuth token probably has a class similar
>> to this, simple enough but why reinvent the wheel every time.
>>
>>
>>
>> /**
>> * Represents the JSON response returned when refreshing / adding a new
>> OAuth token
>> */
>> @Data
>> *public* *class* NewOAuthTokenResponse {
>>
>> @JsonProperty("access_token")
>> *private* String accessToken;
>>
>> @JsonProperty("refresh_token")
>> *private* String refreshToken;
>>
>> @JsonIgnore
>> *private* Instant expiryTime;
>> *private* String scope;
>>
>> @JsonProperty("token_type")
>> *private* *static* String *TOKEN_TYPE* = "bearer";
>>
>> @JsonProperty("expires_in")
>> *public* Long expiresIn() {
>> *return* Duration. *between*(Instant. *now*(), expiryTime).getSeconds();
>> }
>>
>> }
>>
>>
>> On 05 April 2020 at 14:11 Brian Demers <br...@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 <bo...@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 < richard@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.demers@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 < lhazlewood@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.demers@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.papon@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çoisfpapon@apache.org
>>
>>
>>
>>
>>
>>
>> --
>> Rob Young
>> robertjohnyoung@gmail.com
>>
>>
>>
>>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Francois Papon <fr...@openobject.fr>.
Agree, for me Shiro is not the place to implement an Authorization Server, Shiro is more a framework.
regards,
François
fpapon@apache.org
Le 06/04/2020 à 16:40, Brian Demers a écrit :
> Personally I don't think Shiro should implement an Authorization
> Server, I think there is room for another project to implement on
> using Shiro (and Shiro would likely benefit from this). This is
> actually a major undertaking. The Spring Security folks tried to drop
> support for this
> recently: https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update IIRC,
> they are still supporting this use case though.
>
> I have a bias opinion on this topic, so someone else please chime in.
> In most cases, you probably wouldn't want to run your own
> authorization server, but instead, use a different one KeyCloak if you
> want to run it yourself, Okta, Microsoft, Google, etc if you don't.
>
> I could be in the minority here, what do others think?
>
>
>
> On Mon, Apr 6, 2020 at 4:21 AM Richard Adams
> <richard@researchspace.com <ma...@researchspace.com>> wrote:
>
> A framework or implementation of standard authorisation server
> endpoints such as /oauth/token for
> standard grant types such as refresh_token, password,
> authorisation_code etc. e.g described here
> https://aaronparecki.com/oauth-2-simplified/
> <https://aaronparecki.com/oauth-2-simplified/#authorization>
> Could be a servlet filter, but if so should delegate to a handler
> which can be used in other places e.g. Spring Interceptors,
> Controllers, standalone applications etc. The Shiro approach of a
> standard out-of-the-box implementation with lots of configurable
> /overridable functionality would work well here, along with
> reference classes for the various types of token.
> E.g. anyone returning JSON of an OAuth token probably has a class
> similar to this, simple enough but why reinvent the wheel every time.
>
>
>
> /**
> * Represents the JSON response returned when refreshing / adding
> a new OAuth token
> */
> @Data
> *public* *class* NewOAuthTokenResponse {
>
> @JsonProperty("access_token")
> *private* String accessToken;
>
> @JsonProperty("refresh_token")
> *private* String refreshToken;
>
> @JsonIgnore
> *private* Instant expiryTime;
> *private* String scope;
>
> @JsonProperty("token_type")
> *private* *static* String /TOKEN_TYPE/ = "bearer";
>
> @JsonProperty("expires_in")
> *public* Long expiresIn() {
> *return* Duration. /between/(Instant. /now/(),
> expiryTime).getSeconds();
> }
>
> }
>
>
>> On 05 April 2020 at 14:11 Brian Demers <brian.demers@gmail.com
>> <ma...@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 <bobbotron@gmail.com
>>> <ma...@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 <
>>> richard@researchspace.com <ma...@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.demers@gmail.com <ma...@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 <
>>>>> lhazlewood@apache.org <ma...@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.demers@gmail.com <ma...@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.papon@openobject.fr
>>>>> <ma...@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çois
>>>>> fpapon@apache.org <ma...@apache.org>
>>>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Rob Young
>>> robertjohnyoung@gmail.com <ma...@gmail.com>
>>>
>
>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
Personally I don't think Shiro should implement an Authorization Server, I
think there is room for another project to implement on using Shiro (and
Shiro would likely benefit from this). This is actually a major
undertaking. The Spring Security folks tried to drop support for this
recently:
https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update
IIRC,
they are still supporting this use case though.
I have a bias opinion on this topic, so someone else please chime in. In
most cases, you probably wouldn't want to run your own
authorization server, but instead, use a different one KeyCloak if you want
to run it yourself, Okta, Microsoft, Google, etc if you don't.
I could be in the minority here, what do others think?
On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <ri...@researchspace.com>
wrote:
> A framework or implementation of standard authorisation server endpoints
> such as /oauth/token for
> standard grant types such as refresh_token, password, authorisation_code
> etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
> <https://aaronparecki.com/oauth-2-simplified/#authorization>
> Could be a servlet filter, but if so should delegate to a handler which
> can be used in other places e.g. Spring Interceptors, Controllers,
> standalone applications etc. The Shiro approach of a standard
> out-of-the-box implementation with lots of configurable /overridable
> functionality would work well here, along with reference classes for the
> various types of token.
> E.g. anyone returning JSON of an OAuth token probably has a class similar
> to this, simple enough but why reinvent the wheel every time.
>
>
>
> /**
> * Represents the JSON response returned when refreshing / adding a new
> OAuth token
> */
> @Data
> *public* *class* NewOAuthTokenResponse {
>
> @JsonProperty("access_token")
> *private* String accessToken;
>
> @JsonProperty("refresh_token")
> *private* String refreshToken;
>
> @JsonIgnore
> *private* Instant expiryTime;
> *private* String scope;
>
> @JsonProperty("token_type")
> *private* *static* String *TOKEN_TYPE* = "bearer";
>
> @JsonProperty("expires_in")
> *public* Long expiresIn() {
> *return* Duration. *between*(Instant. *now*(), expiryTime).getSeconds();
> }
>
> }
>
>
> On 05 April 2020 at 14:11 Brian Demers <br...@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 <bo...@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 < richard@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.demers@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 < lhazlewood@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.demers@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.papon@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çoisfpapon@apache.org
>
>
>
>
>
>
> --
> Rob Young
> robertjohnyoung@gmail.com
>
>
>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Richard Adams <ri...@researchspace.com>.
A framework or implementation of standard authorisation server endpoints such
as /oauth/token for
standard grant types such as refresh_token, password, authorisation_code etc.
e.g described here
[https://aaronparecki.com/oauth-2-simplified/](https://aaronparecki.com/oauth-2-simplified/#authorization)
Could be a servlet filter, but if so should delegate to a handler which can
be used in other places e.g. Spring Interceptors, Controllers, standalone
applications etc. The Shiro approach of a standard out-of-the-box
implementation with lots of configurable /overridable functionality would work
well here, along with reference classes for the various types of token.
E.g. anyone returning JSON of an OAuth token probably has a class similar to
this, simple enough but why reinvent the wheel every time.
/**
* Represents the JSON response returned when refreshing / adding a new OAuth token
*/
@Data
**public** **class** NewOAuthTokenResponse {
@JsonProperty("access_token")
**private** String accessToken;
@JsonProperty("refresh_token")
**private** String refreshToken;
@JsonIgnore
**private** Instant expiryTime;
**private** String scope;
@JsonProperty("token_type")
**private** **static** String _TOKEN_TYPE_ = "bearer";
@JsonProperty("expires_in")
**public** Long expiresIn() {
**return** Duration. _between_ (Instant. _now_ (), expiryTime).getSeconds();
}
}
> On 05 April 2020 at 14:11 Brian Demers <br...@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 <bo...@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 <
[richard@researchspace.com](mailto:richard@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.demers@gmail.com](mailto:brian.demers@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 <
[lhazlewood@apache.org](mailto:lhazlewood@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.demers@gmail.com](mailto:brian.demers@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.papon@openobject.fr](mailto:francois.papon@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çois
>>>>>>> [fpapon@apache.org](mailto:fpapon@apache.org)
>>>
>>>
>
>>
>>
>
> \--
>
>>
>> Rob Young
>>
>> [robertjohnyoung@gmail.com](mailto:robertjohnyoung@gmail.com)
>>
>>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Francois Papon <fr...@openobject.fr>.
Yes, +1 for OAuth support!
regards,
François
fpapon@apache.org
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 <bo...@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
>> <richard@researchspace.com <ma...@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.demers@gmail.com
>>> <ma...@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
>>>> <lhazlewood@apache.org <ma...@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.demers@gmail.com <ma...@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.papon@openobject.fr
>>>> <ma...@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çois
>>>> fpapon@apache.org <ma...@apache.org>
>>>>
>>
>>
>>
>>
>>
>> --
>> Rob Young
>> robertjohnyoung@gmail.com <ma...@gmail.com>
>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Rob Young <bo...@gmail.com>.
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 <br...@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 <bo...@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 <ri...@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 <br...@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 <lh...@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.demers@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.papon@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çoisfpapon@apache.org
>>
>>
>>
>>
>
>
> --
> Rob Young
> robertjohnyoung@gmail.com
>
>
--
Rob Young
robertjohnyoung@gmail.com
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
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 <bo...@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 <ri...@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 <br...@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 <lh...@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.demers@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.papon@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çois
>>>> fpapon@apache.org
>>
>>
>
>
> --
> Rob Young
> robertjohnyoung@gmail.com
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Rob Young <bo...@gmail.com>.
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 <ri...@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 <br...@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 <lh...@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.demers@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.papon@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çoisfpapon@apache.org
>
>
>
>
--
Rob Young
robertjohnyoung@gmail.com
Re: [DISCUSS] - Move to 2.0.0
Posted by Richard Adams <ri...@researchspace.com>.
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 <br...@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 <lh...@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.demers@gmail.com](mailto:brian.demers@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.papon@openobject.fr](mailto:francois.papon@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çois
>>>> [fpapon@apache.org](mailto:fpapon@apache.org)
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
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 <lh...@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 <br...@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 <fr...@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çois
>>> fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
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 <lh...@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 <br...@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 <fr...@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çois
>>> fpapon@apache.org
Re: [DISCUSS] - Move to 2.0.0
Posted by Les Hazlewood <lh...@apache.org>.
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 <br...@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.papon@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çoisfpapon@apache.org
>>
>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Les Hazlewood <lh...@apache.org>.
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 <br...@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.papon@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çoisfpapon@apache.org
>>
>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
+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 <fr...@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çoisfpapon@apache.org
>
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi,
I think we can improve a bit around that without bunch of export.
I can work on this.
Regards
JB
> Le 7 avr. 2020 à 10:47, Steinar Bang <sb...@dod.no> a écrit :
>
>>>>>> Francois Papon <fr...@public.gmane.org>:
>
>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>
> Maybe a bit OSGi-centric: but how about a restructuring around OSGi
> services and DS components providing these services?
>
> (Shiro is already partly there already. At least Realm and SessionDAO
> have this kind of structure, but there may be others I don't know about)
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
Thanks Francois!
On Thu, May 7, 2020 at 5:51 AM Francois Papon <fr...@openobject.fr>
wrote:
> FYI
>
> https://issues.apache.org/jira/browse/SHIRO-768
>
> regards,
>
> Françoisfpapon@apache.org
>
> Le 07/05/2020 à 11:44, Benjamin Marwell a écrit :
>
> +1
>
>
>
>
> On Thu, 7 May 2020, 04:13 Francois Papon, <fr...@openobject.fr>
> wrote:
>
>> +1
>>
>> Françoisfpapon@apache.org
>>
>> Le 07/05/2020 à 00:28, Brian Demers a écrit :
>>
>> I'd love to see the `shiro-all` module go away as part of 2.0, anyone
>> have any objections?
>>
>> On Mon, May 4, 2020 at 4:32 AM sreenivas harshith <sr...@yahoo.com>
>> wrote:
>>
>>> Some libs were broken from java 9 and above due to java 9 module system
>>> and JDK internal APIs restrictions. Just wanted to check if shiro supports
>>> Java 9 and above.
>>>
>>>
>>> On Mon, May 4, 2020 at 1:12 PM +0530, "Francois Papon" <
>>> francois.papon@openobject.fr> wrote:
>>>
>>> I am using Shiro with a Jdk11 and I never had issues.
>>>>
>>>> We also have a Jenkins job for the build with JDK11 but the target
>>>> build for the source code still Java 8.
>>>>
>>>> regards,
>>>>
>>>> Françoisfpapon@apache.org
>>>>
>>>> Le 04/05/2020 à 09:30, Benjamin Marwell a écrit :
>>>>
>>>> I never had issues with it, but there is no module descriptor yet.
>>>> Thus, it depends on what you mean by "support java9".
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, 4 May 2020, 04:40 sreenivas harshith, <sr...@yahoo.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Does shiro support java 9 and above ?
>>>>>
>>>>> Regards,
>>>>> Sreenivas.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, May 3, 2020 at 4:27 PM +0530, <fp...@apache.org> wrote:
>>>>>
>>>>> Hi all,
>>>>>>
>>>>>> The 1.5.3 is released now, so I created a branch 1.5.x for the
>>>>>> maintenance and move the master to the 2.0.0-SNAPSHOT.
>>>>>>
>>>>>> We will now review the 2.0.0 backlog on Jira and merge some ideas from
>>>>>> this thread.
>>>>>>
>>>>>> Feel free to create issues related to this next major version and make
>>>>>> proposals / PR:
>>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>>>
>>>>>> Thanks for all your feedback!
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Françoisfpapon@apache.org
>>>>>>
>>>>>> Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>>>>> >>>>>> Francois Papon :
>>>>>> >>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>>>> > Speaking purely for myself, I would like to see this one fixed:
>>>>>> > https://issues.apache.org/jira/browse/SHIRO-713
>>>>>>
>>>>>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Francois Papon <fr...@openobject.fr>.
FYI
https://issues.apache.org/jira/browse/SHIRO-768
regards,
François
fpapon@apache.org
Le 07/05/2020 à 11:44, Benjamin Marwell a écrit :
> +1
>
>
>
>
> On Thu, 7 May 2020, 04:13 Francois Papon,
> <francois.papon@openobject.fr <ma...@openobject.fr>>
> wrote:
>
> +1
>
> François
> fpapon@apache.org <ma...@apache.org>
>
> Le 07/05/2020 à 00:28, Brian Demers a écrit :
>> I'd love to see the `shiro-all` module go away as part of 2.0,
>> anyone have any objections?
>>
>> On Mon, May 4, 2020 at 4:32 AM sreenivas harshith
>> <sreenivash09@yahoo.com <ma...@yahoo.com>> wrote:
>>
>> Some libs were broken from java 9 and above due to java 9
>> module system and JDK internal APIs restrictions. Just wanted
>> to check if shiro supports Java 9 and above.
>>
>>
>> On Mon, May 4, 2020 at 1:12 PM +0530, "Francois Papon"
>> <francois.papon@openobject.fr
>> <ma...@openobject.fr>> wrote:
>>
>> I am using Shiro with a Jdk11 and I never had issues.
>>
>> We also have a Jenkins job for the build with JDK11 but
>> the target build for the source code still Java 8.
>>
>> regards,
>>
>> François
>> fpapon@apache.org <ma...@apache.org>
>>
>> Le 04/05/2020 à 09:30, Benjamin Marwell a écrit :
>>> I never had issues with it, but there is no module
>>> descriptor yet. Thus, it depends on what you mean by
>>> "support java9".
>>>
>>>
>>>
>>>
>>> On Mon, 4 May 2020, 04:40 sreenivas harshith,
>>> <sreenivash09@yahoo.com <ma...@yahoo.com>>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> Does shiro support java 9 and above ?
>>>
>>> Regards,
>>> Sreenivas.
>>>
>>>
>>>
>>> On Sun, May 3, 2020 at 4:27 PM +0530,
>>> <fpapon@apache.org <ma...@apache.org>> wrote:
>>>
>>> Hi all,
>>>
>>> The 1.5.3 is released now, so I created a branch 1.5.x for the
>>> maintenance and move the master to the 2.0.0-SNAPSHOT.
>>>
>>> We will now review the 2.0.0 backlog on Jira and merge some ideas from
>>> this thread.
>>>
>>> Feel free to create issues related to this next major version and make
>>> proposals / PR:
>>>
>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>
>>> Thanks for all your feedback!
>>>
>>> regards,
>>>
>>> François
>>> fpapon@apache.org <ma...@apache.org>
>>>
>>> Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>> >>>>>> Francois Papon :
>>> >>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>> > Speaking purely for myself, I would like to see this one fixed:
>>> > https://issues.apache.org/jira/browse/SHIRO-713
>>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Benjamin Marwell <bm...@gmail.com>.
+1
On Thu, 7 May 2020, 04:13 Francois Papon, <fr...@openobject.fr>
wrote:
> +1
>
> Françoisfpapon@apache.org
>
> Le 07/05/2020 à 00:28, Brian Demers a écrit :
>
> I'd love to see the `shiro-all` module go away as part of 2.0, anyone have
> any objections?
>
> On Mon, May 4, 2020 at 4:32 AM sreenivas harshith <sr...@yahoo.com>
> wrote:
>
>> Some libs were broken from java 9 and above due to java 9 module system
>> and JDK internal APIs restrictions. Just wanted to check if shiro supports
>> Java 9 and above.
>>
>>
>> On Mon, May 4, 2020 at 1:12 PM +0530, "Francois Papon" <
>> francois.papon@openobject.fr> wrote:
>>
>> I am using Shiro with a Jdk11 and I never had issues.
>>>
>>> We also have a Jenkins job for the build with JDK11 but the target build
>>> for the source code still Java 8.
>>>
>>> regards,
>>>
>>> Françoisfpapon@apache.org
>>>
>>> Le 04/05/2020 à 09:30, Benjamin Marwell a écrit :
>>>
>>> I never had issues with it, but there is no module descriptor yet. Thus,
>>> it depends on what you mean by "support java9".
>>>
>>>
>>>
>>>
>>> On Mon, 4 May 2020, 04:40 sreenivas harshith, <sr...@yahoo.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Does shiro support java 9 and above ?
>>>>
>>>> Regards,
>>>> Sreenivas.
>>>>
>>>>
>>>>
>>>> On Sun, May 3, 2020 at 4:27 PM +0530, <fp...@apache.org> wrote:
>>>>
>>>> Hi all,
>>>>>
>>>>> The 1.5.3 is released now, so I created a branch 1.5.x for the
>>>>> maintenance and move the master to the 2.0.0-SNAPSHOT.
>>>>>
>>>>> We will now review the 2.0.0 backlog on Jira and merge some ideas from
>>>>> this thread.
>>>>>
>>>>> Feel free to create issues related to this next major version and make
>>>>> proposals / PR:
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>>
>>>>> Thanks for all your feedback!
>>>>>
>>>>> regards,
>>>>>
>>>>> Françoisfpapon@apache.org
>>>>>
>>>>> Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>>>> >>>>>> Francois Papon :
>>>>> >>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>>> > Speaking purely for myself, I would like to see this one fixed:
>>>>> > https://issues.apache.org/jira/browse/SHIRO-713
>>>>>
>>>>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Francois Papon <fr...@openobject.fr>.
+1
François
fpapon@apache.org
Le 07/05/2020 à 00:28, Brian Demers a écrit :
> I'd love to see the `shiro-all` module go away as part of 2.0, anyone
> have any objections?
>
> On Mon, May 4, 2020 at 4:32 AM sreenivas harshith
> <sreenivash09@yahoo.com <ma...@yahoo.com>> wrote:
>
> Some libs were broken from java 9 and above due to java 9 module
> system and JDK internal APIs restrictions. Just wanted to check if
> shiro supports Java 9 and above.
>
>
> On Mon, May 4, 2020 at 1:12 PM +0530, "Francois Papon"
> <francois.papon@openobject.fr
> <ma...@openobject.fr>> wrote:
>
> I am using Shiro with a Jdk11 and I never had issues.
>
> We also have a Jenkins job for the build with JDK11 but the
> target build for the source code still Java 8.
>
> regards,
>
> François
> fpapon@apache.org <ma...@apache.org>
>
> Le 04/05/2020 à 09:30, Benjamin Marwell a écrit :
>> I never had issues with it, but there is no module descriptor
>> yet. Thus, it depends on what you mean by "support java9".
>>
>>
>>
>>
>> On Mon, 4 May 2020, 04:40 sreenivas harshith,
>> <sreenivash09@yahoo.com <ma...@yahoo.com>> wrote:
>>
>> Hi all,
>>
>> Does shiro support java 9 and above ?
>>
>> Regards,
>> Sreenivas.
>>
>>
>>
>> On Sun, May 3, 2020 at 4:27 PM +0530, <fpapon@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Hi all,
>>
>> The 1.5.3 is released now, so I created a branch 1.5.x for the
>> maintenance and move the master to the 2.0.0-SNAPSHOT.
>>
>> We will now review the 2.0.0 backlog on Jira and merge some ideas from
>> this thread.
>>
>> Feel free to create issues related to this next major version and make
>> proposals / PR:
>>
>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>
>> Thanks for all your feedback!
>>
>> regards,
>>
>> François
>> fpapon@apache.org <ma...@apache.org>
>>
>> Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>> >>>>>> Francois Papon :
>> >>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>> > Speaking purely for myself, I would like to see this one fixed:
>> > https://issues.apache.org/jira/browse/SHIRO-713
>>
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
I'd love to see the `shiro-all` module go away as part of 2.0, anyone have
any objections?
On Mon, May 4, 2020 at 4:32 AM sreenivas harshith <sr...@yahoo.com>
wrote:
> Some libs were broken from java 9 and above due to java 9 module system
> and JDK internal APIs restrictions. Just wanted to check if shiro supports
> Java 9 and above.
>
>
> On Mon, May 4, 2020 at 1:12 PM +0530, "Francois Papon" <
> francois.papon@openobject.fr> wrote:
>
> I am using Shiro with a Jdk11 and I never had issues.
>>
>> We also have a Jenkins job for the build with JDK11 but the target build
>> for the source code still Java 8.
>>
>> regards,
>>
>> Françoisfpapon@apache.org
>>
>> Le 04/05/2020 à 09:30, Benjamin Marwell a écrit :
>>
>> I never had issues with it, but there is no module descriptor yet. Thus,
>> it depends on what you mean by "support java9".
>>
>>
>>
>>
>> On Mon, 4 May 2020, 04:40 sreenivas harshith, <sr...@yahoo.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> Does shiro support java 9 and above ?
>>>
>>> Regards,
>>> Sreenivas.
>>>
>>>
>>>
>>> On Sun, May 3, 2020 at 4:27 PM +0530, <fp...@apache.org> wrote:
>>>
>>> Hi all,
>>>>
>>>> The 1.5.3 is released now, so I created a branch 1.5.x for the
>>>> maintenance and move the master to the 2.0.0-SNAPSHOT.
>>>>
>>>> We will now review the 2.0.0 backlog on Jira and merge some ideas from
>>>> this thread.
>>>>
>>>> Feel free to create issues related to this next major version and make
>>>> proposals / PR:
>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>
>>>> Thanks for all your feedback!
>>>>
>>>> regards,
>>>>
>>>> Françoisfpapon@apache.org
>>>>
>>>> Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>>> >>>>>> Francois Papon :
>>>> >>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>> > Speaking purely for myself, I would like to see this one fixed:
>>>> > https://issues.apache.org/jira/browse/SHIRO-713
>>>>
>>>>
Re: [DISCUSS] - Move to 2.0.0
Posted by sreenivas harshith <sr...@yahoo.com>.
Some libs were broken from java 9 and above due to java 9 module system and JDK internal APIs restrictions. Just wanted to check if shiro supports Java 9 and above.
On Mon, May 4, 2020 at 1:12 PM +0530, "Francois Papon" <fr...@openobject.fr> wrote:
I am using Shiro with a Jdk11 and I never had issues.
We also have a Jenkins job for the build with JDK11 but the
target build for the source code still Java 8.
regards,
François
fpapon@apache.org
Le 04/05/2020 à 09:30, Benjamin Marwell
a écrit :
I never had issues with
it, but there is no module descriptor yet. Thus, it depends on
what you mean by "support java9".
On Mon, 4 May 2020, 04:40
sreenivas harshith, <sr...@yahoo.com>
wrote:
Hi all,
Does shiro support
java 9 and above ?
Regards,
Sreenivas.
On Sun, May 3, 2020 at 4:27 PM
+0530, <fp...@apache.org>
wrote:
Hi all,
The 1.5.3 is released now, so I created a branch 1.5.x for the
maintenance and move the master to the 2.0.0-SNAPSHOT.
We will now review the 2.0.0 backlog on Jira and merge some ideas from
this thread.
Feel free to create issues related to this next major version and make
proposals / PR:
https://issues.apache.org/jira/projects/SHIRO/versions/12315455
Thanks for all your feedback!
regards,
François
fpapon@apache.org
Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>>>>> Francois Papon :
>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
> Speaking purely for myself, I would like to see this one fixed:
> https://issues.apache.org/jira/browse/SHIRO-713
Re: [DISCUSS] - Move to 2.0.0
Posted by Francois Papon <fr...@openobject.fr>.
I am using Shiro with a Jdk11 and I never had issues.
We also have a Jenkins job for the build with JDK11 but the target build
for the source code still Java 8.
regards,
François
fpapon@apache.org
Le 04/05/2020 à 09:30, Benjamin Marwell a écrit :
> I never had issues with it, but there is no module descriptor yet.
> Thus, it depends on what you mean by "support java9".
>
>
>
>
> On Mon, 4 May 2020, 04:40 sreenivas harshith, <sreenivash09@yahoo.com
> <ma...@yahoo.com>> wrote:
>
> Hi all,
>
> Does shiro support java 9 and above ?
>
> Regards,
> Sreenivas.
>
>
>
> On Sun, May 3, 2020 at 4:27 PM +0530, <fpapon@apache.org
> <ma...@apache.org>> wrote:
>
> Hi all,
>
> The 1.5.3 is released now, so I created a branch 1.5.x for the
> maintenance and move the master to the 2.0.0-SNAPSHOT.
>
> We will now review the 2.0.0 backlog on Jira and merge some ideas from
> this thread.
>
> Feel free to create issues related to this next major version and make
> proposals / PR:
>
> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>
> Thanks for all your feedback!
>
> regards,
>
> François
> fpapon@apache.org <ma...@apache.org>
>
> Le 08/04/2020 à 18:55, Steinar Bang a écrit :
> >>>>>> Francois Papon :
> >>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
> > Speaking purely for myself, I would like to see this one fixed:
> > https://issues.apache.org/jira/browse/SHIRO-713
>
Re: [DISCUSS] - Move to 2.0.0
Posted by Benjamin Marwell <bm...@gmail.com>.
I never had issues with it, but there is no module descriptor yet. Thus, it
depends on what you mean by "support java9".
On Mon, 4 May 2020, 04:40 sreenivas harshith, <sr...@yahoo.com>
wrote:
> Hi all,
>
> Does shiro support java 9 and above ?
>
> Regards,
> Sreenivas.
>
>
>
> On Sun, May 3, 2020 at 4:27 PM +0530, <fp...@apache.org> wrote:
>
> Hi all,
>>
>> The 1.5.3 is released now, so I created a branch 1.5.x for the
>> maintenance and move the master to the 2.0.0-SNAPSHOT.
>>
>> We will now review the 2.0.0 backlog on Jira and merge some ideas from
>> this thread.
>>
>> Feel free to create issues related to this next major version and make
>> proposals / PR:
>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>
>> Thanks for all your feedback!
>>
>> regards,
>>
>> Françoisfpapon@apache.org
>>
>> Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>> >>>>>> Francois Papon :
>> >>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>> > Speaking purely for myself, I would like to see this one fixed:
>> > https://issues.apache.org/jira/browse/SHIRO-713
>>
>>
Re: [DISCUSS] - Move to 2.0.0
Posted by sreenivas harshith <sr...@yahoo.com>.
Hi all,
Does shiro support java 9 and above ?
Regards,Sreenivas.
On Sun, May 3, 2020 at 4:27 PM +0530, <fp...@apache.org> wrote:
Hi all,
The 1.5.3 is released now, so I created a branch 1.5.x for the
maintenance and move the master to the 2.0.0-SNAPSHOT.
We will now review the 2.0.0 backlog on Jira and merge some ideas from
this thread.
Feel free to create issues related to this next major version and make
proposals / PR:
https://issues.apache.org/jira/projects/SHIRO/versions/12315455
Thanks for all your feedback!
regards,
François
fpapon@apache.org
Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>>>>> Francois Papon :
>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
> Speaking purely for myself, I would like to see this one fixed:
> https://issues.apache.org/jira/browse/SHIRO-713
Re: [DISCUSS] - Move to 2.0.0
Posted by fp...@apache.org.
Hi all,
The 1.5.3 is released now, so I created a branch 1.5.x for the
maintenance and move the master to the 2.0.0-SNAPSHOT.
We will now review the 2.0.0 backlog on Jira and merge some ideas from
this thread.
Feel free to create issues related to this next major version and make
proposals / PR:
https://issues.apache.org/jira/projects/SHIRO/versions/12315455
Thanks for all your feedback!
regards,
François
fpapon@apache.org
Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>>>>> Francois Papon <fr...@public.gmane.org>:
>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
> Speaking purely for myself, I would like to see this one fixed:
> https://issues.apache.org/jira/browse/SHIRO-713
Re: [DISCUSS] - Move to 2.0.0
Posted by fp...@apache.org.
Hi all,
The 1.5.3 is released now, so I created a branch 1.5.x for the
maintenance and move the master to the 2.0.0-SNAPSHOT.
We will now review the 2.0.0 backlog on Jira and merge some ideas from
this thread.
Feel free to create issues related to this next major version and make
proposals / PR:
https://issues.apache.org/jira/projects/SHIRO/versions/12315455
Thanks for all your feedback!
regards,
François
fpapon@apache.org
Le 08/04/2020 à 18:55, Steinar Bang a écrit :
>>>>>> Francois Papon <fr...@public.gmane.org>:
>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
> Speaking purely for myself, I would like to see this one fixed:
> https://issues.apache.org/jira/browse/SHIRO-713
Re: [DISCUSS] - Move to 2.0.0
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Francois Papon <fr...@public.gmane.org>:
>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
Speaking purely for myself, I would like to see this one fixed:
https://issues.apache.org/jira/browse/SHIRO-713
Re: [DISCUSS] - Move to 2.0.0
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Francois Papon <fr...@public.gmane.org>:
> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
Maybe a bit OSGi-centric: but how about a restructuring around OSGi
services and DS components providing these services?
(Shiro is already partly there already. At least Realm and SessionDAO
have this kind of structure, but there may be others I don't know about)
Re: [DISCUSS] - Move to 2.0.0
Posted by Brian Demers <br...@gmail.com>.
+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 <fr...@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çoisfpapon@apache.org
>
>