Re: Future of Wicket Security (WASP/SWARM)
On Monday 25 January 2010 15:59:53 James Carman wrote: > On Mon, Jan 25, 2010 at 9:50 AM, Emond Papegaaij > > Most of the complicated stuff is from SWARM, which indeed requires a lot > > of configuration. The difference between WASP and SWARM is not quite > > clear from the documentation, nor is the separation of the two. Some of > > the naming could use some improvement indeed :). The HiveMind manages the > > Hives used in the VM. A Hive contains all principals and permissions of > > an application and ultimately determines if a permission is granted or > > not. However, the Hive (and mind) are part of SWARM and should not be > > part of a general API. > > > > The main elements of WASP are: > > - A set of secure components > > - Several security checks > > - The ActionFactory, with a set of default actions > > - The WaspAuthorizationStrategy, which implements IAuthorizationStrategy > > > > With this, WASP only provides an interface to make you Wicket application > > secure. It has no implementation what-so-ever on how to check the > > security. Therefore, I think it is a good starting point for creating a > > general security API for Wicket. > > So, what does WASP add to wicket-auth-roles that it doesn't have > already? Is it generic enough that we should just put it into > wicket-auth-roles (or a new wicket-security module)? I really don't > like the name WASP. I think wicket-security is intuitive enough (and > follows the other names already out there wicket-ioc, wicket-spring, > etc.). I really don't like the fact that when folks ask questions > about wicket-auth-roles, the usual answer is "wicket-auth-roles is > only a demonstration" or something to that effect. There really > should be a sanctioned/preferred (and pluggable) security framework > for Wicket that we can all get behind. I think WASP is a good name for what it is now: a separate project. A general security framework for wicket should be named wicket-security. WASP makes it possible to authorize single components, models of components and classes. This authorization can be performed on multiple levels, not just RENDER and ENABLE. It also provides the ISecurityCheck interface, which can be used to create reusable security checks. Some default implementations are already provided. The secure components are components that are used often, such as a SecurePageLink that is only visible when the target is authorized. I don't think WASP (or wicket-security) should be integrated into wicket-auth- roles, but auth-roles should be one of the security providers available for Wicket. My vision is that WASP replaces the interfaces in Wicket itself (such as IAuthorizationStrategy) and become part of the core of Wicket. Other frameworks can then build on this interface. However, as I said before, currently WASP is too bloated to be considered as a 'general security API'. Emond - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Mon, Jan 25, 2010 at 9:50 AM, Emond Papegaaij wrote: > I think a good security framework needs to provide an API that allows, but not > require, fine-grained control. > Exactly! That's what I'm looking for. For the folks who want to get down-and-dirty and really tighten the screws on their authorization, they can do that. But, for me and my somewhat limited authorization concerns, I'd like to use something simple. > Most of the complicated stuff is from SWARM, which indeed requires a lot of > configuration. The difference between WASP and SWARM is not quite clear from > the documentation, nor is the separation of the two. Some of the naming could > use some improvement indeed :). The HiveMind manages the Hives used in the VM. > A Hive contains all principals and permissions of an application and > ultimately determines if a permission is granted or not. However, the Hive > (and mind) are part of SWARM and should not be part of a general API. > > The main elements of WASP are: > - A set of secure components > - Several security checks > - The ActionFactory, with a set of default actions > - The WaspAuthorizationStrategy, which implements IAuthorizationStrategy > > With this, WASP only provides an interface to make you Wicket application > secure. It has no implementation what-so-ever on how to check the security. > Therefore, I think it is a good starting point for creating a general security > API for Wicket. > So, what does WASP add to wicket-auth-roles that it doesn't have already? Is it generic enough that we should just put it into wicket-auth-roles (or a new wicket-security module)? I really don't like the name WASP. I think wicket-security is intuitive enough (and follows the other names already out there wicket-ioc, wicket-spring, etc.). I really don't like the fact that when folks ask questions about wicket-auth-roles, the usual answer is "wicket-auth-roles is only a demonstration" or something to that effect. There really should be a sanctioned/preferred (and pluggable) security framework for Wicket that we can all get behind. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Monday 25 January 2010 15:22:42 James Carman wrote: > On Mon, Jan 25, 2010 at 9:11 AM, Emond Papegaaij > > The current wicket-security code is somewhat limited in what you can do > > with it. WASP provides a much richer (probably too rich) interface for > > security. I see WASP as a viable basis for the wicket-security API where > > providers can plug in to. One of these providers will be SWARM, but also > > wicket-security- shiro and wicket-security-spring. Maybe even auth-roles. > > Agreed it's limited, so we should definitely make the API rich enough > so that you can do very fine-grained authorization control or more > coarse-grained. Some projects (like ours) will be okay with just > saying "this page has to have this role." I think a good security framework needs to provide an API that allows, but not require, fine-grained control. > > However WASP in its current state is a too bloated for this. It will > > require a major cleanup. On the other hand, the current wicket-security > > API is too limited for a real security framework to plug in to. For this > > to work, we need to find the fine line that provides a clean, but > > complete API. > > Agreed. When I look at the documentation for SWARM/WASP, I cringe. > I, being one of the (now defunct) Apache HiveMind committers, also > take offense to the name of the HiveMind class. :) Actually, I really > don't like the cutesy names in the API at all. The names don't make > any sense? Why is a "hive" called a "hive" for instance? Why is the > HiveMind class called HiveMind. Just looking at it, it's really not > intuitive. There also seems to be a lot of configuration required to > get things off the ground properly. Most of the complicated stuff is from SWARM, which indeed requires a lot of configuration. The difference between WASP and SWARM is not quite clear from the documentation, nor is the separation of the two. Some of the naming could use some improvement indeed :). The HiveMind manages the Hives used in the VM. A Hive contains all principals and permissions of an application and ultimately determines if a permission is granted or not. However, the Hive (and mind) are part of SWARM and should not be part of a general API. The main elements of WASP are: - A set of secure components - Several security checks - The ActionFactory, with a set of default actions - The WaspAuthorizationStrategy, which implements IAuthorizationStrategy With this, WASP only provides an interface to make you Wicket application secure. It has no implementation what-so-ever on how to check the security. Therefore, I think it is a good starting point for creating a general security API for Wicket. Emond - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Mon, Jan 25, 2010 at 9:11 AM, Emond Papegaaij wrote: > I didn't mean that providing a general framework for security providers is > overkill, just that modifying SWARM to be usable outside a Wicket-environment > is overkill. There is no need to split SWARM into a general security framework > and a Wicket integration part. > And I didn't intend to imply that either. > The current wicket-security code is somewhat limited in what you can do with > it. WASP provides a much richer (probably too rich) interface for security. I > see WASP as a viable basis for the wicket-security API where providers can > plug in to. One of these providers will be SWARM, but also wicket-security- > shiro and wicket-security-spring. Maybe even auth-roles. > Agreed it's limited, so we should definitely make the API rich enough so that you can do very fine-grained authorization control or more coarse-grained. Some projects (like ours) will be okay with just saying "this page has to have this role." > However WASP in its current state is a too bloated for this. It will require a > major cleanup. On the other hand, the current wicket-security API is too > limited for a real security framework to plug in to. For this to work, we need > to find the fine line that provides a clean, but complete API. > Agreed. When I look at the documentation for SWARM/WASP, I cringe. I, being one of the (now defunct) Apache HiveMind committers, also take offense to the name of the HiveMind class. :) Actually, I really don't like the cutesy names in the API at all. The names don't make any sense? Why is a "hive" called a "hive" for instance? Why is the HiveMind class called HiveMind. Just looking at it, it's really not intuitive. There also seems to be a lot of configuration required to get things off the ground properly. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Monday 25 January 2010 14:31:47 James Carman wrote: > On Mon, Jan 25, 2010 at 8:07 AM, Emond Papegaaij > > wrote: > > That sounds a bit overkill to me. I don't think anyone will ever want to > > use SWARM in a non-Wicket application. Naturally, this is a bit different > > for Shiro and spring-security, because these are existing projects (if > > I'm not mistaken), which can also be used without Wicket. > > Overkill? It's not overkill to provide a framework where you can plug > in providers. I didn't say that SWARM should be used outside of > Wicket (I personally wouldn't use it anywhere because I think it's too > complicated). What I was saying was that any security "framework" for > Wicket should allow you to bring your own security provider (shiro, > spring-security, etc). That's exactly what the wicket-security code > provides right now with the AuthenticatedWebApplication, > AuthenticatedWebSession, etc. I didn't mean that providing a general framework for security providers is overkill, just that modifying SWARM to be usable outside a Wicket-environment is overkill. There is no need to split SWARM into a general security framework and a Wicket integration part. The current wicket-security code is somewhat limited in what you can do with it. WASP provides a much richer (probably too rich) interface for security. I see WASP as a viable basis for the wicket-security API where providers can plug in to. One of these providers will be SWARM, but also wicket-security- shiro and wicket-security-spring. Maybe even auth-roles. However WASP in its current state is a too bloated for this. It will require a major cleanup. On the other hand, the current wicket-security API is too limited for a real security framework to plug in to. For this to work, we need to find the fine line that provides a clean, but complete API. Emond Papegaaij - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Mon, Jan 25, 2010 at 8:07 AM, Emond Papegaaij wrote: > That sounds a bit overkill to me. I don't think anyone will ever want to use > SWARM in a non-Wicket application. Naturally, this is a bit different for > Shiro and spring-security, because these are existing projects (if I'm not > mistaken), which can also be used without Wicket. Overkill? It's not overkill to provide a framework where you can plug in providers. I didn't say that SWARM should be used outside of Wicket (I personally wouldn't use it anywhere because I think it's too complicated). What I was saying was that any security "framework" for Wicket should allow you to bring your own security provider (shiro, spring-security, etc). That's exactly what the wicket-security code provides right now with the AuthenticatedWebApplication, AuthenticatedWebSession, etc. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Monday 25 January 2010 13:02:05 James Carman wrote: > On Mon, Jan 25, 2010 at 6:11 AM, Emond Papegaaij > > wrote: > > I do think this is a good idea, however it will be difficult to > > implement. WASP/SWARM already provides this setup. WASP defines the > > interface, where SWARM is the implementation of that interface. I do not > > know about Shiro, but I don't think it is implemented on top of WASP. So > > should SWARM be build on top of the abstractions provided by Shiro (does > > it even have those abstractions?) or should Shiro be build on top of > > WASP? Either way will require a lot of work. > > Shiro shouldn't have to know anything about WASP. What should happen > is Wicket-Security (or whatever we're going to call it) would declare > a "SPI" interface that could be implemented to adapt any security > framework (spring-security, shiro, etc.) to the Wicket-Security API. > The security frameworks themselves wouldn't necessarily (most likely > they would not) implement the interface; there would be an integration > library (e.g. wicket-security-shiro) that bridges the gap. That sounds a bit overkill to me. I don't think anyone will ever want to use SWARM in a non-Wicket application. Naturally, this is a bit different for Shiro and spring-security, because these are existing projects (if I'm not mistaken), which can also be used without Wicket. WASP (Wicket Abstract Security Platform) is what could serve as a basis for what you call 'the Wicket-Security API'. It will require some work to make it more generic and less 'SWARM'-like, but I think the concept is quite good. This can then serve as a basis to build security providers, such as wicket- security-shiro, wicket-security-spring and SWARM. Emond Papegaaij - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Mon, Jan 25, 2010 at 6:11 AM, Emond Papegaaij wrote: > I do think this is a good idea, however it will be difficult to implement. > WASP/SWARM already provides this setup. WASP defines the interface, where > SWARM is the implementation of that interface. I do not know about Shiro, but > I don't think it is implemented on top of WASP. So should SWARM be build on > top of the abstractions provided by Shiro (does it even have those > abstractions?) or should Shiro be build on top of WASP? Either way will > require a lot of work. Shiro shouldn't have to know anything about WASP. What should happen is Wicket-Security (or whatever we're going to call it) would declare a "SPI" interface that could be implemented to adapt any security framework (spring-security, shiro, etc.) to the Wicket-Security API. The security frameworks themselves wouldn't necessarily (most likely they would not) implement the interface; there would be an integration library (e.g. wicket-security-shiro) that bridges the gap. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
I do think this is a good idea, however it will be difficult to implement. WASP/SWARM already provides this setup. WASP defines the interface, where SWARM is the implementation of that interface. I do not know about Shiro, but I don't think it is implemented on top of WASP. So should SWARM be build on top of the abstractions provided by Shiro (does it even have those abstractions?) or should Shiro be build on top of WASP? Either way will require a lot of work. I don't know who is the maintainer of Shiro, but I don't mind changing WASP to allow Shiro to be build on top of it, or the other way around (building SWARM on top of Shiro). Perhaps this core security framework can then be integrated into the wicket core. However, I doubt if such a thing can be accomplished for wicket 1.5 (or at all). Best regards, Emond Papegaaij On Monday 25 January 2010 11:11:31 nino martinez wael wrote: > No one has a feeling about making a "super/parent" security framework for > wicket and then let providers implement their solution.. Like JPA ? It > would mean that it would be the same using Shiro or Swarm / Wasp etc.. You > just switch provider? > > 2010/1/22 nino martinez wael > > > I am in doubt. What I think would be best are creating a parent framework > > like wicket ioc. And then the different security providers could use > > that.. Does it seem reasonable? > > > > That would mean keeping Wicket security at stuff, but probably extracting > > interfaces? And maybe adopting a few committers from wicket shiro / > > wicket security and if there are other integrations to a sub project at > > Apache Wicket, to make it less of a burden as Igor writes. > > > > > > > > [ ] adopt Wicket security into Apache Wicket > > [X ] keep Wicket security at Wicket Stuff > > > > 2010/1/22 Martijn Dashorst > > > > Guys, > > > >> I'd like to discuss the future of the Wicket Security project. > >> Currently the project lives on/in the wicketstuff repository, but uses > >> group id and package names "org.apache.wicket". IMO We should either: > >> > >> - adopt Wicket Security into the Wicket project and move everything > >> over from Wicket Stuff into a subproject within Apache Wicket (and > >> adopt the committers), or > >> - keep Wicket Security at wicketstuff and move it into the fold of > >> wicket stuff, including groupid/package rename. > >> > >> Since development on wicket security 1.4 is currently happening with a > >> 1.4-beta1 just released, it is prudent to decide its future now (with > >> a pending package rename). > >> > >> Considering that both the wicket security contributors and the Wicket > >> PMC members are needed to make this happen, all their opinions are > >> considered binding. > >> > >> [ ] adopt Wicket security into Apache Wicket > >> [ ] keep Wicket security at Wicket Stuff > >> > >> Martijn > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
No one has a feeling about making a "super/parent" security framework for wicket and then let providers implement their solution.. Like JPA ? It would mean that it would be the same using Shiro or Swarm / Wasp etc.. You just switch provider? 2010/1/22 nino martinez wael > I am in doubt. What I think would be best are creating a parent framework > like wicket ioc. And then the different security providers could use that.. > Does it seem reasonable? > > That would mean keeping Wicket security at stuff, but probably extracting > interfaces? And maybe adopting a few committers from wicket shiro / wicket > security and if there are other integrations to a sub project at Apache > Wicket, to make it less of a burden as Igor writes. > > > > [ ] adopt Wicket security into Apache Wicket > [X ] keep Wicket security at Wicket Stuff > > 2010/1/22 Martijn Dashorst > > Guys, >> >> I'd like to discuss the future of the Wicket Security project. >> Currently the project lives on/in the wicketstuff repository, but uses >> group id and package names "org.apache.wicket". IMO We should either: >> >> - adopt Wicket Security into the Wicket project and move everything >> over from Wicket Stuff into a subproject within Apache Wicket (and >> adopt the committers), or >> - keep Wicket Security at wicketstuff and move it into the fold of >> wicket stuff, including groupid/package rename. >> >> Since development on wicket security 1.4 is currently happening with a >> 1.4-beta1 just released, it is prudent to decide its future now (with >> a pending package rename). >> >> Considering that both the wicket security contributors and the Wicket >> PMC members are needed to make this happen, all their opinions are >> considered binding. >> >> [ ] adopt Wicket security into Apache Wicket >> [ ] keep Wicket security at Wicket Stuff >> >> Martijn >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >
Re: Future of Wicket Security (WASP/SWARM)
Also -1 on bringing it into core. I don't feel it has wide enough adoption to justify it being maintained by core committers. There's too many security options out there. -- Jeremy Thomerson http://www.wickettraining.com On Fri, Jan 22, 2010 at 10:53 AM, Igor Vaynberg wrote: > -1 on bringing this into the core. its more code to maintain and we > are busy enough already making improvements to the core itself. > > -igor > > On Fri, Jan 22, 2010 at 1:52 AM, Martijn Dashorst > wrote: > > Guys, > > > > I'd like to discuss the future of the Wicket Security project. > > Currently the project lives on/in the wicketstuff repository, but uses > > group id and package names "org.apache.wicket". IMO We should either: > > > > - adopt Wicket Security into the Wicket project and move everything > > over from Wicket Stuff into a subproject within Apache Wicket (and > > adopt the committers), or > > - keep Wicket Security at wicketstuff and move it into the fold of > > wicket stuff, including groupid/package rename. > > > > Since development on wicket security 1.4 is currently happening with a > > 1.4-beta1 just released, it is prudent to decide its future now (with > > a pending package rename). > > > > Considering that both the wicket security contributors and the Wicket > > PMC members are needed to make this happen, all their opinions are > > considered binding. > > > > [ ] adopt Wicket security into Apache Wicket > > [ ] keep Wicket security at Wicket Stuff > > > > Martijn > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Future of Wicket Security (WASP/SWARM)
I am in doubt. What I think would be best are creating a parent framework like wicket ioc. And then the different security providers could use that.. Does it seem reasonable? That would mean keeping Wicket security at stuff, but probably extracting interfaces? And maybe adopting a few committers from wicket shiro / wicket security and if there are other integrations to a sub project at Apache Wicket, to make it less of a burden as Igor writes. [ ] adopt Wicket security into Apache Wicket [X ] keep Wicket security at Wicket Stuff 2010/1/22 Martijn Dashorst > Guys, > > I'd like to discuss the future of the Wicket Security project. > Currently the project lives on/in the wicketstuff repository, but uses > group id and package names "org.apache.wicket". IMO We should either: > > - adopt Wicket Security into the Wicket project and move everything > over from Wicket Stuff into a subproject within Apache Wicket (and > adopt the committers), or > - keep Wicket Security at wicketstuff and move it into the fold of > wicket stuff, including groupid/package rename. > > Since development on wicket security 1.4 is currently happening with a > 1.4-beta1 just released, it is prudent to decide its future now (with > a pending package rename). > > Considering that both the wicket security contributors and the Wicket > PMC members are needed to make this happen, all their opinions are > considered binding. > > [ ] adopt Wicket security into Apache Wicket > [ ] keep Wicket security at Wicket Stuff > > Martijn > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Future of Wicket Security (WASP/SWARM)
-1 on bringing this into the core. its more code to maintain and we are busy enough already making improvements to the core itself. -igor On Fri, Jan 22, 2010 at 1:52 AM, Martijn Dashorst wrote: > Guys, > > I'd like to discuss the future of the Wicket Security project. > Currently the project lives on/in the wicketstuff repository, but uses > group id and package names "org.apache.wicket". IMO We should either: > > - adopt Wicket Security into the Wicket project and move everything > over from Wicket Stuff into a subproject within Apache Wicket (and > adopt the committers), or > - keep Wicket Security at wicketstuff and move it into the fold of > wicket stuff, including groupid/package rename. > > Since development on wicket security 1.4 is currently happening with a > 1.4-beta1 just released, it is prudent to decide its future now (with > a pending package rename). > > Considering that both the wicket security contributors and the Wicket > PMC members are needed to make this happen, all their opinions are > considered binding. > > [ ] adopt Wicket security into Apache Wicket > [ ] keep Wicket security at Wicket Stuff > > Martijn > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
Hi Martijn! > [ ] adopt Wicket security into Apache Wicket > [x] keep Wicket security at Wicket Stuff Best regards, --- Jan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Fri, Jan 22, 2010 at 5:07 PM, Ben Tilford wrote: > Assuming adopting it into Apache Wicket would mean being in the wicket jar > instead of an optional jar. Huh? What part of > - adopt Wicket Security into the Wicket project and move everything > over from Wicket Stuff into a subproject within Apache Wicket (and > adopt the committers), or is unclear? Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
Assuming adopting it into Apache Wicket would mean being in the wicket jar instead of an optional jar. [ ] adopt Wicket security into Apache Wicket [x] keep Wicket security at Wicket Stuff On Fri, Jan 22, 2010 at 11:00 AM, Les Hazlewood wrote: > > [ ] adopt Wicket security into Apache Wicket > > [x] keep Wicket security at Wicket Stuff > > I am biased, yes, but I much prefer Shiro in my Wicket apps too :) > > - Les > > On Fri, Jan 22, 2010 at 10:03 AM, Martin Grigorov > wrote: > > On Fri, 2010-01-22 at 10:52 +0100, Martijn Dashorst wrote: > >> Guys, > >> > >> I'd like to discuss the future of the Wicket Security project. > >> Currently the project lives on/in the wicketstuff repository, but uses > >> group id and package names "org.apache.wicket". IMO We should either: > >> > >> - adopt Wicket Security into the Wicket project and move everything > >> over from Wicket Stuff into a subproject within Apache Wicket (and > >> adopt the committers), or > >> - keep Wicket Security at wicketstuff and move it into the fold of > >> wicket stuff, including groupid/package rename. > >> > >> Since development on wicket security 1.4 is currently happening with a > >> 1.4-beta1 just released, it is prudent to decide its future now (with > >> a pending package rename). > >> > >> Considering that both the wicket security contributors and the Wicket > >> PMC members are needed to make this happen, all their opinions are > >> considered binding. > >> > >> [ ] adopt Wicket security into Apache Wicket > >> [x] keep Wicket security at Wicket Stuff > > I haven't seen in the mailing lists many users of it. Most of them use > > Spring Security (my statistics). > > > > I think there is no need to add one more thing to support by the core > > committers. > > > > P.S. I personally prefer Shiro. > >> > >> Martijn > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Future of Wicket Security (WASP/SWARM)
> [ ] adopt Wicket security into Apache Wicket > [x] keep Wicket security at Wicket Stuff I am biased, yes, but I much prefer Shiro in my Wicket apps too :) - Les On Fri, Jan 22, 2010 at 10:03 AM, Martin Grigorov wrote: > On Fri, 2010-01-22 at 10:52 +0100, Martijn Dashorst wrote: >> Guys, >> >> I'd like to discuss the future of the Wicket Security project. >> Currently the project lives on/in the wicketstuff repository, but uses >> group id and package names "org.apache.wicket". IMO We should either: >> >> - adopt Wicket Security into the Wicket project and move everything >> over from Wicket Stuff into a subproject within Apache Wicket (and >> adopt the committers), or >> - keep Wicket Security at wicketstuff and move it into the fold of >> wicket stuff, including groupid/package rename. >> >> Since development on wicket security 1.4 is currently happening with a >> 1.4-beta1 just released, it is prudent to decide its future now (with >> a pending package rename). >> >> Considering that both the wicket security contributors and the Wicket >> PMC members are needed to make this happen, all their opinions are >> considered binding. >> >> [ ] adopt Wicket security into Apache Wicket >> [x] keep Wicket security at Wicket Stuff > I haven't seen in the mailing lists many users of it. Most of them use > Spring Security (my statistics). > > I think there is no need to add one more thing to support by the core > committers. > > P.S. I personally prefer Shiro. >> >> Martijn >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
I am a user of Wicket Security and I would prefer: [x] adopt Wicket security into Apache Wicket [] keep Wicket security at Wicket Stuff best regards giovanni From: Martin Grigorov To: users@wicket.apache.org Cc: d...@wicket.apache.org Sent: Fri, January 22, 2010 4:03:48 PM Subject: Re: Future of Wicket Security (WASP/SWARM) On Fri, 2010-01-22 at 10:52 +0100, Martijn Dashorst wrote: > Guys, > > I'd like to discuss the future of the Wicket Security project. > Currently the project lives on/in the wicketstuff repository, but uses > group id and package names "org.apache.wicket". IMO We should either: > > - adopt Wicket Security into the Wicket project and move everything > over from Wicket Stuff into a subproject within Apache Wicket (and > adopt the committers), or > - keep Wicket Security at wicketstuff and move it into the fold of > wicket stuff, including groupid/package rename. > > Since development on wicket security 1.4 is currently happening with a > 1.4-beta1 just released, it is prudent to decide its future now (with > a pending package rename). > > Considering that both the wicket security contributors and the Wicket > PMC members are needed to make this happen, all their opinions are > considered binding. > > [ ] adopt Wicket security into Apache Wicket > [x] keep Wicket security at Wicket Stuff I haven't seen in the mailing lists many users of it. Most of them use Spring Security (my statistics). I think there is no need to add one more thing to support by the core committers. P.S. I personally prefer Shiro. > > Martijn > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
On Fri, 2010-01-22 at 10:52 +0100, Martijn Dashorst wrote: > Guys, > > I'd like to discuss the future of the Wicket Security project. > Currently the project lives on/in the wicketstuff repository, but uses > group id and package names "org.apache.wicket". IMO We should either: > > - adopt Wicket Security into the Wicket project and move everything > over from Wicket Stuff into a subproject within Apache Wicket (and > adopt the committers), or > - keep Wicket Security at wicketstuff and move it into the fold of > wicket stuff, including groupid/package rename. > > Since development on wicket security 1.4 is currently happening with a > 1.4-beta1 just released, it is prudent to decide its future now (with > a pending package rename). > > Considering that both the wicket security contributors and the Wicket > PMC members are needed to make this happen, all their opinions are > considered binding. > > [ ] adopt Wicket security into Apache Wicket > [x] keep Wicket security at Wicket Stuff I haven't seen in the mailing lists many users of it. Most of them use Spring Security (my statistics). I think there is no need to add one more thing to support by the core committers. P.S. I personally prefer Shiro. > > Martijn > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
[ ] adopt Wicket security into Apache Wicket > [x ] keep Wicket security at Wicket Stuff > > Pulling more code into Apache Wicket doesn't look like the best option to me. Looking at http://www.ohloh.net/p/wicket/contributors?query=&sort=latest_commit I'd be more interesed in ideas of creating more commitment to the project. mf
Future of Wicket Security (WASP/SWARM)
Guys, I'd like to discuss the future of the Wicket Security project. Currently the project lives on/in the wicketstuff repository, but uses group id and package names "org.apache.wicket". IMO We should either: - adopt Wicket Security into the Wicket project and move everything over from Wicket Stuff into a subproject within Apache Wicket (and adopt the committers), or - keep Wicket Security at wicketstuff and move it into the fold of wicket stuff, including groupid/package rename. Since development on wicket security 1.4 is currently happening with a 1.4-beta1 just released, it is prudent to decide its future now (with a pending package rename). Considering that both the wicket security contributors and the Wicket PMC members are needed to make this happen, all their opinions are considered binding. [ ] adopt Wicket security into Apache Wicket [ ] keep Wicket security at Wicket Stuff Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
