cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: SSF
Date Thu, 27 Mar 2008 23:33:02 GMT
To be honest, I've found using a ServletFilter as a better way of doing 
authentication than the auth framework. It would be fairly trivial to 
create one that only allows the signon page and login requests through 
until a login is successful.

Patrick Heiden wrote:
>
>
> Well maybe I get something wrong with block-semantics. I'll try to explain. I thought
it would be a good idea to have a mainController wich is responsible for main routings and
authentication. So users actually logged in can get access to hosted blocks services (checked
before any routing gets through, thats why I called for cocoon-auth details ;)).
>
> Imagine several domainModules wich are connected to blocks - each block responsible for
handling requests of special module. So far there is nothing special about it, reflecting
adviced block-design. Again there would be other blocks, responsible for layout or user-navigation
rendering. But what (and this is the main point) if user calls some block (e.g. rendering
block as standalone, wich should be avoided) in isolation? There would be no security-check
and no usage of mainControllers aggregate, composing final views out of hosted blocks.
>
> Inside mainControllers sitemap I use the conventional pipeline with id="service" to do
high-level routings like:
>
> <map:pipeline id="service">
>    <map:match pattern="callSomeServiceBlock/*.do">
>               <map:generate 
>                    src="servlet:whereEverServiceIs:/{1}.do" 
>                    type="file"/>
>               <map:serialize type="xml"/>
>    </map:match>
>
>    <map:match pattern="callSomeOtherServiceBlock/*.do">
>               <map:generate 
>                    src="servlet:whereEverOtherIs:/{1}.do" 
>                    type="file"/>
>               <map:serialize type="xml"/>
>    </map:match>
> </map:pipeline>
>
> So the *.do's would be processed in serviceBlocks-sitemaps (I would do the same for continuations
as well). I could use some aggregates to build final views:
>
> <map:pipeline id="serviceRouter">
>    <map:match pattern="callSome/**.do">
>       <map:aggregate element="final">
>          <map:part src="part_one.xml"/>
>          <map:part src="part_two.xml"/>
>          <map:part src="cocoon:/callSomeServiceBlock/{1}.do"/>
>       </map:aggregate>
>
>       <SOME TRANSFORMATIONS HERE/>
>
>       <map:serialize type="html"/>
>    </map:match>
>
> <!-- more matchers here -->
>
> </map:pipeline>
>
> I hope this makes clear what I want to achieve. My problem is authentication of that
as a whole to avoid the auth-dependence inside every block. With above I could also use a
'**' pattern to redirect to login or something like you-are-not-logged-in... But still there
would be the problem, that one could call mounted blocks direct, bypassing my serviceRouter.
>   
>> Do I overlook something obvious?
>>     
>
> I wouldn't guess! Hopefully I am the one making things unnecessary  overcomplex ;) -
due to the fact that I have no other auth-source then the block-samples.
>
> Looking forward for comments,
> best regards,
> Patrick
>   
>> -- 
>> Grzegorz Kossakowski
>>     
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message