cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Heiden" <>
Subject Re: SSF
Date Thu, 27 Mar 2008 23:00:08 GMT
As always: Thanks a lot!

> Patrick Heiden pisze:
> >> The other possibility (maybe better one) could be to let the auth-block
> and rendering block
> >> stand alone and then let the service blocks depend on them.
> > 
> > This has still the 'disadvantage' of users beeing able to call blocks
> directly.
> You should use Spring AOP support (concretely: before advice) for stuff
> like this (more below).
> > Grzegorz: I recognized the updated SSF-documentation with new image
> about DispatcherServlet[1]
> > (nice!). 
> Thanks. Those images are little bit messed up. Will have to look what's
> happening out there.
> > There it is pointed out, that ONLY DispatcherServlet (wich acts as the
> > mainControllerBlock) sould delegate requests. My mentioned
> 'disadvantage' is still true. What am
> > I missing in this 'simple' design? Or am I just adding useless
> complexity due to my thoughts
> > about authentication?
> Authentication, authorization, limiting the access - all of these things
> are perfect use-cases for 
> Spring's AOP support[1]. You should create before advice on servlet's (in
> thise case: 
> SitemapServlet) service() method. I mentioned this approach in
> discussion[2] with Robin Wyles.

Yeah, I know about AOP and will check[2] tomorrow! Pretty good idea in the first place and
somewhat naturally in sense of block semantics themselfs are somewhat orthogonal ;) This is
going to be interesting since cocoon-auth is able to get used inside flowscripts. Those could
of course get called through myAuth-blocks sitemap (in case of complex checks as you mentioned

> Once you get your AOP advice configured you can do anything you like. You
> can delegate to auth-block 
> in order to check if user is logged in and has enough karma to access the
> block/resource. If your 
> checks become complicated you could create separate block with sitemap
> where all patterns could be 
> stored. Then you could use sitemap's powerful matchers for matching
> request and responding with 
> approporiate HTTP status code that your _advice_ would read and decide
> whether to continue the 
> processing or inform user that she is not allowed to access the resource.
> Possibilities are endless.
> What's important here is that with creation of AOP advice you don't break
> basic contract that it's 
> only DispatcherServlet allowed to dispatch requests. In the end, you don't
> want to establish 
> competition to DispatcherServlet but only tweak it a little bit, right?

Exactly, not interested in reinventing the wheel ;) Maybe a better/realistic auth-example
could erase such doubts. I will put such stuff inside my final tutorial about mainController
design and sample application. 

> AOP techniques are very powerful in such cases and it's great coincidence
> that you can take 
> advantage of them while using SSF. :-)

Absolutely. Besides: Please feel free to point out locations inside cocoon-docs where my contribution
could be usefull. I am always faster in learning when clear goals are given behind!

> [1]
> [2]
> -- 
> Respects,
> Grzegorz Kossakowski

GMX startet Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message