shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Nielsen <mny...@gmail.com>
Subject Re: I would like to help OSGI'fy Shiro, if you will have me.
Date Wed, 18 May 2016 16:23:50 GMT
I have now made some (Very) slow and (Kind of) steady progress. Sorry about
the long wait time.

https://github.com/mnybon/shiro

Please note: This is only for the Shiro 2-Alpha version. It was a lot
easier for me to start there. If Shiro-2 is not released within the
foreseeable future, i will attempt to make the same changes to the current
Shiro branch, which should be a lot faster and easier with my newfound
practice.

I have made the first push and created a number of OSGi bundles for the
common Shiro-Core components. I have also created a Realm that integrates
with the Felix ConfigurationAdmin. Lastly i have added a Pax-Exam
integration test which, at the moment, only has a single test worth
mentioning. I have tried to keep my fingers out of the base Shiro code as
much as i could, and i think it has worked reasonably well.

I still have some work to do, going thorough the new bundles and checking
imports and especially exports, updating javadoc and clearning imports, but
the current state of the project should at least give you a pretty good
idea of my direction.

I have not created a pull request yet, as that should probably be postponed
until Shiro-Web has recieved the same attention as Shiro-Core.
But could i convince some of you very wise and skilled Shiro contributors
to take a look at the work and see if you can agree with the direction I'm
going in, or if i am completely insane?

I will wait a little with continuing, until i hear a verdict:)

Another thing to consider: Right now I have created seperate bundle
projects that pretty much just extend the different Shiro-Core components,
but it would be simpler (i think) to just seperate the components out into
seperate modules, and use an aggregation project to collect them all into
the "Shiro-Core" and "Shiro-Web" Jars. It would be a lot easier for the
OSGi implementation, as it would remove the need for what is essentially
shadow-bundles, but it would introduce at least two new aggregations
projects. What are your thoughts there?

Changes i have made to the Shiro we all know and love (Excluding new
classes).
I have made Shiro Core into a Declarative Services component. This has
allowed me to inject the SecurityManager into SecurityUtils, which should
ensure that all the shiro-based applications that use
SecurityUtils.getSubject will still work in an OSGi context.
I made a slight addition to DelegatingSubject, by allowing the constructor
to inject a SecurityManager Source. This is needed in order to seperate out
the SecurityManager retrieval logic, so it can be replaced with the OSGi
Service Registry when needed.
I delegated the choice of what exactly gets saved to the Thread, to
ThreadState, allowing SecurityManagers and DelegatingSubjects greater
control over what gets saved to the Thread. I needed this in order to make
SecurityUtils work with OSGi, without actually touching the class.
I tweaked a few ThreadState tests, as i needed to reprogram a few of the
Mocks.
Lastly, i have made select changes to the Shiro-Root POM.

Additions i have made (New stuff that doesn't impact the normal application:
I created OSGi-enabled Declarative Service bundles of the most common Shiro
Core classes (SecurityManager, SessionManager, SessionDAO and so forth)
A new Realm has joined the family as well, It is similar to the
Configuration Realms, but uses the Felix Configuration Admin instead of
config files.
Shiro now has an OSGi Integration Test

(And now I think that I have used my allowance of the word "I", I
apologize:) )

Thanks in advance
-Martin

On Fri, Apr 15, 2016 at 2:57 PM, Martin Nielsen <mnybon@gmail.com> wrote:

> Christiano:
> I am looking into the Coordinator now, and it seems that it would indeed
> be a good substitute for the ThreadLocal approach for the
> "single-classloader" implementation. But have you had any thought about how
> (or if) to make the two ways compatible? I would very much like if existing
> shiro-enabled applications could simply be dropped into an OSGi container,
> and still work using SecurityUtils.getSubject and the like, not to mention
> that most of the filters and existing code frequently use the same
> approach. I am looking into using DeclarativeServices to make sure that the
> static SecurityManager is always set to a real functioning instance of the
> SecurityManager service, for this purpose.
> Any thoughts?
>
> Taking all the help i can get!
> -Martin
>
> On Thu, Apr 14, 2016 at 4:40 PM, Brian Demers <brian.demers@gmail.com>
> wrote:
>
>> Adding new methods to interfaces breaks backwards compatibility.
>>
>>
>> On Thu, Apr 14, 2016 at 10:00 AM, Cristiano GaviĆ£o <cvgaviao@gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > I was not able to find the code that I did... I've bought a new notebook
>> > and seems that I left it on the old one...
>> >
>> > Well, one of the main goals of the Coordinator Service was to deal with
>> > the problem of holding things on the ThreadLocal while calling a
>> > sequence/chain flowing by different bundles providing OSGi services due
>> to
>> > the bundles isolation characteristic.   take a look on the spec.
>> >
>> > If I remember well, my experiments was madden in order to integrate the
>> > ServiceManager with the Coordinator. the path I took was..:
>> >
>> > When the first service in the call chain is reached (started by means
>> of a
>> > direct call or a remote service call or by a http call) one
>> *coordination*
>> > is created/started (from the coordinator service object)... Then inside
>> its
>> > bootstrap method the securitymanager is used to get a subject/ session
>> (and
>> > any other shiro related object). So, all those objects should be hold
>> > within this unique coordination...
>> >
>> > The coordination object can be passed explicitly or implicitly (using
>> the
>> > call stack) to other bundles that will be followed in the call chain...
>> >
>> > at the end of the call chain the coordination can be stopped (in case of
>> > stateless use), what will trigger the release of every shiro object
>> created
>> > for that coordination.
>> >
>> > You can turn the securitymanager service (or any other class) a
>> > /participant /of the coordination, what can be useful if you need to
>> stop
>> > the current coordination before it reach its end.
>> >
>> > This OSGi model would fit well currently in order to implement the
>> > Environment interface also, which would use the OSGi service register
>> > instead a map to hold the current securitymanager object...  and also
>> some
>> > others default implementations...
>> >
>> > but certainly they will fit better for proposed v2 interfaces that seems
>> > to be much clean and less coupled for service based approach...
>> >
>> > hope it help you.
>> >
>> > regards,
>> >
>> > Cristiano
>> >
>> >
>> > On 14/04/2016 03:33, Martin Nielsen wrote:
>> >
>> >> Cristiano, i will see if i can find your work a little later on. Right
>> now
>> >> my main concern is finding the "least impact" solution for
>> circumventing
>> >> the initialization wiring and threadlocal functionality (Ironically,
>> these
>> >> are some of the things that make Shiro so nice to use, and now i am
>> >> working
>> >> on getting around them).
>> >>
>> >> The main problem i am having right now is that i must not bind
>> anything to
>> >> a threadlocal, that will be exposed as a service (Considering what
>> would
>> >> happen if the corresponding securitymanager bundle is suddenly stopped,
>> >> what about the service instance in the threadlocal?)
>> >>
>> >> Did you do any work along those lines? I would very much like to not
>> >> reinvent the wheel if someone else already did the work.
>> >>
>> >> Right now my thought is to expand the SubjectThreadState, letting the
>> >> subject itself define how it is stored, but i am very much open to
>> other,
>> >> and potentially better, ideas:)
>> >>
>> >> More regards
>> >> -Martin
>> >>
>> >> On Wed, Apr 13, 2016 at 9:11 PM, Brian Demers <brian.demers@gmail.com>
>> >> wrote:
>> >>
>> >> These have been merged to master and 1.2.x
>> >>>
>> >>> On Wed, Apr 13, 2016 at 10:26 AM, Andreas Kohn <
>> andreas.kohn@gmail.com>
>> >>> wrote:
>> >>>
>> >>> Brian,
>> >>>>
>> >>>> We needed[*] to get Shiro 1.2 building with JDK 8, these commits
>> could
>> >>>> be
>> >>>> helpful to pull into the main repository:
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> https://github.com/Collaborne/shiro/commit/e83d73f858bc48cbc7c7123fada099eff044aa43
>> >>>
>> >>>> (SHIRO-516)
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> https://github.com/Collaborne/shiro/commit/631847d3a2754244ad0ab2f87bd581fe7b8e60f7
>> >>>
>> >>>>
>> >>>>
>> >>>
>> https://github.com/Collaborne/shiro/commit/831b90c9255ce81994accef5a94ddfa31a85d8cf
>> >>>
>> >>>>
>> >>>>
>> >>>
>> https://github.com/Collaborne/shiro/commit/be75d27d9439585308ea48420a36d42b53fe7cb2
>> >>>
>> >>>> (no issue/PR yet)
>> >>>>
>> >>>> Should I create a new issue for that, or would that only be relevant
>> for
>> >>>> the mythical Shiro 2.x?
>> >>>>
>> >>>> Regards,
>> >>>> --
>> >>>> Andreas
>> >>>>
>> >>>> [*] JDK 7 is EOL'd, so I simply didn't want to have to bother with
>> that
>> >>>> anymore.
>> >>>>
>> >>>> On Sun, Apr 10, 2016 at 11:02 PM Brian Demers <
>> brian.demers@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>> It should, though use JDK 1.7, if you are not already
>> >>>>>
>> >>>>> -Brian
>> >>>>>
>> >>>>> On Apr 10, 2016, at 7:43 AM, Martin Nielsen <mnybon@gmail.com>
>> >>>>>>
>> >>>>> wrote:
>> >>>
>> >>>> Hi again.
>> >>>>>>
>> >>>>>> I have started ever so slowly, and i have run into the first
issue:
>> >>>>>>
>> >>>>> Compile
>> >>>>>
>> >>>>>> problems:D
>> >>>>>>
>> >>>>>> Either i am missing something, or i have hit the project
at a time
>> >>>>>>
>> >>>>> where
>> >>>>
>> >>>>> it
>> >>>>>
>> >>>>>> doesn't compile. The support/AspectJ project is failing
to compile.
>> >>>>>>
>> >>>>>> Should the project just comple directly from the github
repo? Or
>> do i
>> >>>>>>
>> >>>>> need
>> >>>>>
>> >>>>>> some special setup?
>> >>>>>>
>> >>>>>> If not, i guess i will just start spooling backwards until
i hit a
>> >>>>>>
>> >>>>> commit
>> >>>>
>> >>>>> that compiles:D
>> >>>>>>
>> >>>>>> On Thu, Apr 7, 2016 at 9:25 PM, Brian Demers <
>> >>>>>>>
>> >>>>>> brian.demers@gmail.com>
>> >>>
>> >>>> wrote:
>> >>>>>
>> >>>>>> Martin,
>> >>>>>>> Understood, go for it.
>> >>>>>>>
>> >>>>>>> On Thu, Apr 7, 2016 at 10:32 AM, Martin Nielsen <mnybon@gmail.com
>> >
>> >>>>>>>>
>> >>>>>>> wrote:
>> >>>>>
>> >>>>>> That is the problem, i don't think this will be a "small"
change
>> >>>>>>>>
>> >>>>>>> really.
>> >>>>>
>> >>>>>> I
>> >>>>>>>
>> >>>>>>>> will be making small knicks in quite a few places.
I am up for
>> >>>>>>>>
>> >>>>>>> doing
>> >>>
>> >>>> the
>> >>>>>
>> >>>>>> work, and i am up for modifying it and taking critique.
I wouldn't
>> >>>>>>>>
>> >>>>>>> mind
>> >>>>
>> >>>>> helping to support it afterwards either. I just want to make
sure i
>> >>>>>>>>
>> >>>>>>> don't
>> >>>>>
>> >>>>>> get some answer like "OSGi is not a priority for us, please
sod
>> >>>>>>>>
>> >>>>>>> off"
>> >>>
>> >>>> :D
>> >>>>
>> >>>>> On Thu, Apr 7, 2016 at 3:44 PM, Brian Demers <
>> >>>>>>>>
>> >>>>>>> brian.demers@gmail.com
>> >>>
>> >>>> wrote:
>> >>>>>>>>
>> >>>>>>>> +1 ( including Dan's comments)
>> >>>>>>>>>
>> >>>>>>>>> GitHub pull requests are now preferred.
>> >>>>>>>>>
>> >>>>>>>>> On Thu, Apr 7, 2016 at 9:07 AM, Dan Dumont <ddumont@apache.org>
>> >>>>>>>>>>
>> >>>>>>>>> wrote:
>> >>>>>
>> >>>>>> I don't want to put words in the shiro committers mouths,
but I'm
>> >>>>>>>>>>
>> >>>>>>>>> sure
>> >>>>>>>
>> >>>>>>>> they
>> >>>>>>>>>
>> >>>>>>>>>> would be happy to see the work.  The best
way I found to get
>> >>>>>>>>>>
>> >>>>>>>>> involved
>> >>>>
>> >>>>> in
>> >>>>>>>>
>> >>>>>>>>> Apache projects is to start making small, easy
to review changes
>> >>>>>>>>>>
>> >>>>>>>>> that
>> >>>>
>> >>>>> were
>> >>>>>>>>>
>> >>>>>>>>>> easy to explain.  (With unit tests of course
:)
>> >>>>>>>>>>
>> >>>>>>>>>> Eventually, the community extended a committer
invite.
>> >>>>>>>>>>
>> >>>>>>>>>> Good luck!
>> >>>>>>>>>> I use shiro on karaf right now and would
like to see some love
>> >>>>>>>>>>
>> >>>>>>>>> for
>> >>>
>> >>>> OSGi
>> >>>>>>>
>> >>>>>>>> as
>> >>>>>>>>>
>> >>>>>>>>>> well.
>> >>>>>>>>>>
>> >>>>>>>>>> sent using my nexus 5x
>> >>>>>>>>>>
>> >>>>>>>>>>> On Apr 7, 2016 7:29 AM, "Martin Nielsen"
<mnybon@gmail.com>
>> >>>>>>>>>>>
>> >>>>>>>>>> wrote:
>> >>>>
>> >>>>> Hello Shiro developers.
>> >>>>>>>>>>>
>> >>>>>>>>>>> I have recently been using Shiro for
all my security needs,
>> and
>> >>>>>>>>>>>
>> >>>>>>>>>> I
>> >>>
>> >>>> adore
>> >>>>>>>>
>> >>>>>>>>> the
>> >>>>>>>>>>
>> >>>>>>>>>>> framework. Recently though, I have been
moving more and more
>> >>>>>>>>>>>
>> >>>>>>>>>> towards
>> >>>>>>>
>> >>>>>>>> OSGi
>> >>>>>>>>>
>> >>>>>>>>>> specification, and it feels like Shiro is
a little lacking in
>> >>>>>>>>>>>
>> >>>>>>>>>> that
>> >>>
>> >>>> area.
>> >>>>>>>>>
>> >>>>>>>>>> It
>> >>>>>>>>>>
>> >>>>>>>>>>> works well enough but it is quite static,
and does not really
>> >>>>>>>>>>>
>> >>>>>>>>>> handle
>> >>>>>>>
>> >>>>>>>> the
>> >>>>>>>>>
>> >>>>>>>>>> dynamic nature of OSGi.
>> >>>>>>>>>>>
>> >>>>>>>>>>> As far as I can see, all the wiring
in Shiro on OSGi is one at
>> >>>>>>>>>>> initialization time, and remains static
while the application
>> is
>> >>>>>>>>>>>
>> >>>>>>>>>> running.
>> >>>>>>>>>
>> >>>>>>>>>> I think I have a pretty low impact way to
create an OSGi based
>> >>>>>>>>>>> SecurityManager that would register
Realms, SubjectDAO's,
>> >>>>>>>>>>>
>> >>>>>>>>>> SessionManagers
>> >>>>>>>>>
>> >>>>>>>>>> et cetera as services, allowing bundles
to register their own
>> >>>>>>>>>>> sessionmanagers, cachemanagers, and
more importantly realms,
>> >>>>>>>>>>>
>> >>>>>>>>>> when
>> >>>
>> >>>> they
>> >>>>>>>>
>> >>>>>>>>> start up.
>> >>>>>>>>>>>
>> >>>>>>>>>>> The result would be an OSGi based SecurityManager
that does
>> not
>> >>>>>>>>>>>
>> >>>>>>>>>> start
>> >>>>>>>
>> >>>>>>>> up
>> >>>>>>>>>
>> >>>>>>>>>> statically, for example with an INI file,
but uses the OSGi
>> >>>>>>>>>>>
>> >>>>>>>>>> service
>> >>>>
>> >>>>> registry to get its resources at runtime.
>> >>>>>>>>>>>
>> >>>>>>>>>>> The overall plan is to create a few
changes in Shiro Core and
>> >>>>>>>>>>>
>> >>>>>>>>>> Shiro
>> >>>>
>> >>>>> Web,
>> >>>>>>>>>
>> >>>>>>>>>> so
>> >>>>>>>>>>
>> >>>>>>>>>>> it is possible to define how the individual
parts connects to
>> >>>>>>>>>>>
>> >>>>>>>>>> each
>> >>>
>> >>>> other.
>> >>>>>>>>>
>> >>>>>>>>>> So, basically i want to change hardwired
references to small
>> >>>>>>>>>>>
>> >>>>>>>>>> adapter
>> >>>>>>>
>> >>>>>>>> classes, that can be injected to change how the
components finds
>> >>>>>>>>>>>
>> >>>>>>>>>> each
>> >>>>>>>
>> >>>>>>>> other. The existing SecurityManagers should of cause
remain
>> >>>>>>>>>>>
>> >>>>>>>>>> unaffected
>> >>>>>>>>
>> >>>>>>>>> and
>> >>>>>>>>>>
>> >>>>>>>>>>> there should be no change to the end
user experience.
>> >>>>>>>>>>> I will also create an adapter, that
can be used in place of
>> the
>> >>>>>>>>>>>
>> >>>>>>>>>> static
>> >>>>>>>>
>> >>>>>>>>> securitymanager when running OSGi.
>> >>>>>>>>>>>
>> >>>>>>>>>>> When that is done, I will add a number
of modules to serve as
>> >>>>>>>>>>>
>> >>>>>>>>>> dedicated
>> >>>>>>>>
>> >>>>>>>>> OSGi bundles, using hopefully 95& of the
code from Core and Web,
>> >>>>>>>>>>>
>> >>>>>>>>>> so
>> >>>>
>> >>>>> the
>> >>>>>>>>
>> >>>>>>>>> standard components can be started as separate
bundles, and
>> >>>>>>>>>>>
>> >>>>>>>>>> replaced
>> >>>>>>>
>> >>>>>>>> by
>> >>>>>>>>
>> >>>>>>>>> custom implementations if necessary.
>> >>>>>>>>>>>
>> >>>>>>>>>>> My hope is that, when done, it will
be possible to use a
>> >>>>>>>>>>>
>> >>>>>>>>>> securitymanager
>> >>>>>>>>>
>> >>>>>>>>>> that doesn't wire anything at startup, and
can change at
>> >>>>>>>>>>>
>> >>>>>>>>>> runtime,
>> >>>
>> >>>> as
>> >>>>>>>
>> >>>>>>>> bundles are started and stopped.
>> >>>>>>>>>>>
>> >>>>>>>>>>> I am very willing to put in the hours
to make this happen, but
>> >>>>>>>>>>>
>> >>>>>>>>>> it
>> >>>
>> >>>> would
>> >>>>>>>>
>> >>>>>>>>> be
>> >>>>>>>>>>
>> >>>>>>>>>>> nice to know that this is something
that the maintainers
>> >>>>>>>>>>>
>> >>>>>>>>>> actaully
>> >>>
>> >>>> want,
>> >>>>>>>>
>> >>>>>>>>> so
>> >>>>>>>>>>
>> >>>>>>>>>>> I don't end up with something that isn't
desired. I also have
>> >>>>>>>>>>>
>> >>>>>>>>>> not
>> >>>
>> >>>> worked
>> >>>>>>>>>
>> >>>>>>>>>> that much with the Web bundle, so I might
have some questions
>> >>>>>>>>>>>
>> >>>>>>>>>> down
>> >>>
>> >>>> the
>> >>>>>>>>
>> >>>>>>>>> line.
>> >>>>>>>>>>>
>> >>>>>>>>>>> So: Is this something that that you
would consider a pull
>> >>>>>>>>>>>
>> >>>>>>>>>> request
>> >>>
>> >>>> for?
>> >>>>>>>>
>> >>>>>>>>> Of
>> >>>>>>>>>
>> >>>>>>>>>> cause i can't guarantee that it will work,
but i am willing to
>> >>>>>>>>>>>
>> >>>>>>>>>> try,
>> >>>>
>> >>>>> provided that i get some assurance that it is actually something
>> >>>>>>>>>>>
>> >>>>>>>>>> you
>> >>>>>>>
>> >>>>>>>> want
>> >>>>>>>>>
>> >>>>>>>>>> in the project.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please let me know
>> >>>>>>>>>>>
>> >>>>>>>>>>> Martin Nielsen
>> >>>>>>>>>>> -Hopeful Apache Committer
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message