Fusebox ideas

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Fusebox ideas

Steven Devijver
Hi,

I just got a short demo on fusebox, a PHP based web development framework:

http://www.fusebox.org/

Fusebox is about organizing the structure of website at which in my
opinion Grails does a better job. However, the person that gave me the
walkthrough uses it because it makes outsourcing the development of
specific parts of the application much easier.

A couple of their ideas struct me as interesting and missing in
Grails. Here's how they could be implemented in Grails:

1/ access control settings on controllers:

class MyController {
    static publicAccess = true
}

class MyController {
   static protectedAccess = true
   static requiredRoles = [ "admin" ]
}

2/ dynamically available helper methods:

(in a controller action:)

if (isLoggedOn()) { ... }

These method could be defined in an interface:

interface MyHelper {
    boolean isLoggedOn()
}

That could than be implemented as desired. These methods should be
available in controllers, views and taglibs.

Fusebox is definitely pushing the envelop on seperating concerns.

Steven

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

graemer
Sure, but these should probably be implemented as part of either the
Acegi and/or JSecurity plugins

Cheers

On 10/3/07, Steven Devijver <[hidden email]> wrote:

> Hi,
>
> I just got a short demo on fusebox, a PHP based web development framework:
>
> http://www.fusebox.org/
>
> Fusebox is about organizing the structure of website at which in my
> opinion Grails does a better job. However, the person that gave me the
> walkthrough uses it because it makes outsourcing the development of
> specific parts of the application much easier.
>
> A couple of their ideas struct me as interesting and missing in
> Grails. Here's how they could be implemented in Grails:
>
> 1/ access control settings on controllers:
>
> class MyController {
>     static publicAccess = true
> }
>
> class MyController {
>    static protectedAccess = true
>    static requiredRoles = [ "admin" ]
> }
>
> 2/ dynamically available helper methods:
>
> (in a controller action:)
>
> if (isLoggedOn()) { ... }
>
> These method could be defined in an interface:
>
> interface MyHelper {
>     boolean isLoggedOn()
> }
>
> That could than be implemented as desired. These methods should be
> available in controllers, views and taglibs.
>
> Fusebox is definitely pushing the envelop on seperating concerns.
>
> Steven
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

jondo_w
In reply to this post by Steven Devijver
I like your ideas Steven, but then I do agree with Graeme it's best included in a security plugin.

Neither of the two indicated plugins are perfect unfortunately:
1. Acegi is too complex for simple access implementations
2. JSecurity currently requires a common base controller, which I'd prefer to not be required to do, since I already have a base controller, and the inheritance hierarchy becomes dodgy.

It's a pity there's this proliferation between the security plugins. In addition to those two, there's the AuthTaglib effort that also provides some useful features. And then there's the simplicity and elegance in Stevens points in this thread. I also worked with ASP.NET for a work project here recently, and the ASP.NET Login controls are very easy to put in place, and there are some features there that also provide some inspiration for a simple yet flexible security plugin.

There seems to be a need for a plugin that has simplicity, but flexibility for complexity where needed. To me the Searchable plugin is a great example of that. Simple if you need it to be, but with the capacity for complexity. I've actually been toying with a security plugin that meets all my own needs, but right now it's a bit of a learning curve in terms of hooking into Grails startup code.

Anyway, just my thoughts, to add to what Steven already said.

- Darryl

Steven Devijver wrote
Hi,

I just got a short demo on fusebox, a PHP based web development framework:

http://www.fusebox.org/

Fusebox is about organizing the structure of website at which in my
opinion Grails does a better job. However, the person that gave me the
walkthrough uses it because it makes outsourcing the development of
specific parts of the application much easier.

A couple of their ideas struct me as interesting and missing in
Grails. Here's how they could be implemented in Grails:

1/ access control settings on controllers:

class MyController {
    static publicAccess = true
}

class MyController {
   static protectedAccess = true
   static requiredRoles = [ "admin" ]
}

2/ dynamically available helper methods:

(in a controller action:)

if (isLoggedOn()) { ... }

These method could be defined in an interface:

interface MyHelper {
    boolean isLoggedOn()
}

That could than be implemented as desired. These methods should be
available in controllers, views and taglibs.

Fusebox is definitely pushing the envelop on seperating concerns.

Steven

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Steven Devijver
I agree these features should be part of a security plugin.

I think the currently proliferation of security plugins and their
diverging behaviors could be solved by creating a spec for security
attributes. Each plugin can then implement these as they see fit.

For the Helper interfaces, again this can be a plugin. A helper
interface definition could be part of a future security configuration
spec.

Steven

On 10/3/07, Darryl Pentz <[hidden email]> wrote:

>
> I like your ideas Steven, but then I do agree with Graeme it's best included
> in a security plugin.
>
> Neither of the two indicated plugins are perfect unfortunately:
> 1. Acegi is too complex for simple access implementations
> 2. JSecurity currently requires a common base controller, which I'd prefer
> to not be required to do, since I already have a base controller, and the
> inheritance hierarchy becomes dodgy.
>
> It's a pity there's this proliferation between the security plugins. In
> addition to those two, there's the AuthTaglib effort that also provides some
> useful features. And then there's the simplicity and elegance in Stevens
> points in this thread. I also worked with ASP.NET for a work project here
> recently, and the ASP.NET Login controls are very easy to put in place, and
> there are some features there that also provide some inspiration for a
> simple yet flexible security plugin.
>
> There seems to be a need for a plugin that has simplicity, but flexibility
> for complexity where needed. To me the Searchable plugin is a great example
> of that. Simple if you need it to be, but with the capacity for complexity.
> I've actually been toying with a security plugin that meets all my own
> needs, but right now it's a bit of a learning curve in terms of hooking into
> Grails startup code.
>
> Anyway, just my thoughts, to add to what Steven already said.
>
> - Darryl
>
>
> Steven Devijver wrote:
> >
> > Hi,
> >
> > I just got a short demo on fusebox, a PHP based web development framework:
> >
> > http://www.fusebox.org/
> >
> > Fusebox is about organizing the structure of website at which in my
> > opinion Grails does a better job. However, the person that gave me the
> > walkthrough uses it because it makes outsourcing the development of
> > specific parts of the application much easier.
> >
> > A couple of their ideas struct me as interesting and missing in
> > Grails. Here's how they could be implemented in Grails:
> >
> > 1/ access control settings on controllers:
> >
> > class MyController {
> >     static publicAccess = true
> > }
> >
> > class MyController {
> >    static protectedAccess = true
> >    static requiredRoles = [ "admin" ]
> > }
> >
> > 2/ dynamically available helper methods:
> >
> > (in a controller action:)
> >
> > if (isLoggedOn()) { ... }
> >
> > These method could be defined in an interface:
> >
> > interface MyHelper {
> >     boolean isLoggedOn()
> > }
> >
> > That could than be implemented as desired. These methods should be
> > available in controllers, views and taglibs.
> >
> > Fusebox is definitely pushing the envelop on seperating concerns.
> >
> > Steven
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Fusebox-ideas-tf4560223.html#a13015251
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Daniel.Sun
In reply to this post by graemer
Hi Graeme,

You know, using plugins can make the startup slower than before and the quality of plugin will impact our app.
So providing the basic way to limit access or something like that will be good.

Cheers,
Daniel.Sun
graemer wrote
Sure, but these should probably be implemented as part of either the
Acegi and/or JSecurity plugins

Cheers

On 10/3/07, Steven Devijver <steven.devijver@gmail.com> wrote:
> Hi,
>
> I just got a short demo on fusebox, a PHP based web development framework:
>
> http://www.fusebox.org/
>
> Fusebox is about organizing the structure of website at which in my
> opinion Grails does a better job. However, the person that gave me the
> walkthrough uses it because it makes outsourcing the development of
> specific parts of the application much easier.
>
> A couple of their ideas struct me as interesting and missing in
> Grails. Here's how they could be implemented in Grails:
>
> 1/ access control settings on controllers:
>
> class MyController {
>     static publicAccess = true
> }
>
> class MyController {
>    static protectedAccess = true
>    static requiredRoles = [ "admin" ]
> }
>
> 2/ dynamically available helper methods:
>
> (in a controller action:)
>
> if (isLoggedOn()) { ... }
>
> These method could be defined in an interface:
>
> interface MyHelper {
>     boolean isLoggedOn()
> }
>
> That could than be implemented as desired. These methods should be
> available in controllers, views and taglibs.
>
> Fusebox is definitely pushing the envelop on seperating concerns.
>
> Steven
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Michael Kimsal
Hello all!

I'd like to chime in and expand on Daniels' point here just a bit more.  Having a
default method for some basic level of authentication and authorization in the
Grails framework itself would be a boon for a few reasons. 

1.  A default way would help reduce a multitude of plugins being written to
accomplish roughly the same thing but in numerous incompatible ways.
2.  It would give a standard basis for extending with plugins if need be.
3.  It would make it easier to develop more useful apps 'out of the box'.

Other rationales seem like rehashing of the same ideas, but I'll say that one
of the things I saw in the Rails community early on was that there's wasn't a default
way of handling these sorts of things, and it caused some friction because there
were competing methods of achieving the same thing.  I'm not sure to what
extent that's been solved now, but it was certainly a headache.  Also,
look at the MS method for these sorts of things - throw in many basic defaults
which give people a common basis for understanding a problem (templating, authentication,
whatever) and then let people build on top of that when needed. 

Grails already seems to have a similar approach with session management and templating
techniques - I'm sure I could build a plugin to override the session handling if I was
skilled enough and had a strong enough need, but the defaults do everything
I need right now, and there was very little (no!) set up needed.

While I realize this isn't going to be a 1.0 thing, I'd vote for having something
this common (many people need some degree or access control in an app)
to have a default implementation in the core framework itself.

Thanks all for what Grails as become so far - it's helped me at work a lot the past
few weeks and I'm digging what I'm learning!

On 10/3/07, Daniel.Sun <[hidden email]> wrote:

Hi Graeme,

You know, using plugins can make the startup slower than before and the
quality of plugin will impact our app.
So providing the basic way to limit access or something like that will be
good.

Cheers,
Daniel.Sun


--
Michael Kimsal
http://webdevradio.com
Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Marc Palmer Local
In reply to this post by Steven Devijver

On 3 Oct 2007, at 10:57, Steven Devijver wrote:

> I agree these features should be part of a security plugin.
>
> I think the currently proliferation of security plugins and their
> diverging behaviors could be solved by creating a spec for security
> attributes. Each plugin can then implement these as they see fit.
>
> For the Helper interfaces, again this can be a plugin. A helper
> interface definition could be part of a future security configuration
> spec.
>

I am not sure what use/special need the helpers are for. With plugins  
it is easy to add methods to any artefacts already using  
doWithDynamicMethods and the ExpandoMetaClass.

In applications it may be possible to do this in ApplicationBootstrap  
but I think we definitely need doWithXXX happening for applications too.

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

pledbrook
In reply to this post by jondo_w
On 03/10/2007, Darryl Pentz <[hidden email]> wrote:
>
> I like your ideas Steven, but then I do agree with Graeme it's best included
> in a security plugin.
>
> Neither of the two indicated plugins are perfect unfortunately:
> 1. Acegi is too complex for simple access implementations
> 2. JSecurity currently requires a common base controller, which I'd prefer
> to not be required to do, since I already have a base controller, and the
> inheritance hierarchy becomes dodgy.

True. The question is, do I wait for the web filter plugin, or just
implement one myself for the JSecurity plugin? I'm leaning towards the
latter now.

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Marc Palmer Local
In reply to this post by Michael Kimsal

On 3 Oct 2007, at 12:25, Michael Kimsal wrote:

> Hello all!
>
> I'd like to chime in and expand on Daniels' point here just a bit  
> more.  Having a
> default method for some basic level of authentication and  
> authorization in the
> Grails framework itself would be a boon for a few reasons.
>
> 1.  A default way would help reduce a multitude of plugins being  
> written to
> accomplish roughly the same thing but in numerous incompatible ways.
> 2.  It would give a standard basis for extending with plugins if  
> need be.
> 3.  It would make it easier to develop more useful apps 'out of the  
> box'.
>
> Other rationales seem like rehashing of the same ideas, but I'll  
> say that one
> of the things I saw in the Rails community early on was that  
> there's wasn't a default
> way of handling these sorts of things, and it caused some friction  
> because there
> were competing methods of achieving the same thing.  I'm not sure  
> to what
> extent that's been solved now, but it was certainly a headache.  Also,
> look at the MS method for these sorts of things - throw in many  
> basic defaults
> which give people a common basis for understanding a problem  
> (templating, authentication,
> whatever) and then let people build on top of that when needed.
>
> Grails already seems to have a similar approach with session  
> management and templating
> techniques - I'm sure I could build a plugin to override the  
> session handling if I was
> skilled enough and had a strong enough need, but the defaults do  
> everything
> I need right now, and there was very little (no!) set up needed.

This is exactly the motification behind the Grails Standard Mail  
proposal.

http://grails.org/Grails+Standard+Mail

However there is a problem with security. Messaging is messaging,  
pretty much. The concepts don't vary too much but the transports do.

Authentication and authorisation are done in many different ways. Not  
everyone likes "roles". Some people prefer ACLs, permissions and  
other approaches. It gets rather difficult to support this.

Furthermore authorisation config should be orthogonal to the code,  
rather like Filters are. In fact filters may be the best place for  
this kind of thing... i.e. some kind of:

authBy([role:'administrator'])
authBy([permission:'changeConfig'])

Where the params are a map that is passed to whatever plugin(s) are  
installed to handle authorisation. We could by default build in  
trivial role-based authorisation.

I still think this is best defined as a convention, not code, and a  
reference plugin implementation supplied, which is the concept behind  
Grails Standard Mail.

We might need a hook into the Filters DSL or similar to search for  
plugins that declare they care about authorisation. Perhaps we need a  
new plugin property:

static exposes = ['authorisation':{ impl here }]

Where common names for exposed services are published. Grails filter  
handling would look for all plugins exposing 'authorisation' when it  
hits a filter with authBy, and ask them all if they will permit the  
action or "don't know".

The advantage of this kind of thing is that it means minimal changes  
to get it into core Grails (== sooner) and then the rest is deferred  
to plugin authors.

What do you guys think about this kind of approach? Shall I knock  
together a proposal in sandbox? It will need to wait until after GEX  
because I'm rammed with work and slides and trying to get some Grails  
1.0 tasks done.


Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Marc Palmer Local
In reply to this post by pledbrook

On 3 Oct 2007, at 12:34, Peter Ledbrook wrote:

> On 03/10/2007, Darryl Pentz <[hidden email]> wrote:
>>
>> I like your ideas Steven, but then I do agree with Graeme it's  
>> best included
>> in a security plugin.
>>
>> Neither of the two indicated plugins are perfect unfortunately:
>> 1. Acegi is too complex for simple access implementations
>> 2. JSecurity currently requires a common base controller, which  
>> I'd prefer
>> to not be required to do, since I already have a base controller,  
>> and the
>> inheritance hierarchy becomes dodgy.
>
> True. The question is, do I wait for the web filter plugin, or just
> implement one myself for the JSecurity plugin? I'm leaning towards the
> latter now.
>

Filters are in 1.0-RC1 aren't they? Not tried but that was my  
understanding.

Marc



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Tom Nichols
In reply to this post by Michael Kimsal
+1.  One could argue using similar logic that Grails should not
include a default templating language and it should be provided via
plugin :)  Of course this would be silly and would cause the same sort
of problems that Michael described -- incompatibility, no standard,
and less useful out of the box.  It wouldn't hurt to to give a little
something by default :)

-Tom


On 10/3/07, Michael Kimsal <[hidden email]> wrote:

> Hello all!
>
> I'd like to chime in and expand on Daniels' point here just a bit more.
> Having a
> default method for some basic level of authentication and authorization in
> the
> Grails framework itself would be a boon for a few reasons.
>
> 1.  A default way would help reduce a multitude of plugins being written to
> accomplish roughly the same thing but in numerous incompatible ways.
> 2.  It would give a standard basis for extending with plugins if need be.
> 3.  It would make it easier to develop more useful apps 'out of the box'.
>
> Other rationales seem like rehashing of the same ideas, but I'll say that
> one
> of the things I saw in the Rails community early on was that there's wasn't
> a default
> way of handling these sorts of things, and it caused some friction because
> there
> were competing methods of achieving the same thing.  I'm not sure to what
> extent that's been solved now, but it was certainly a headache.  Also,
> look at the MS method for these sorts of things - throw in many basic
> defaults
> which give people a common basis for understanding a problem (templating,
> authentication,
> whatever) and then let people build on top of that when needed.
>
> Grails already seems to have a similar approach with session management and
> templating
> techniques - I'm sure I could build a plugin to override the session
> handling if I was
> skilled enough and had a strong enough need, but the defaults do everything
> I need right now, and there was very little (no!) set up needed.
>
> While I realize this isn't going to be a 1.0 thing, I'd vote for having
> something
> this common (many people need some degree or access control in an app)
> to have a default implementation in the core framework itself.
>
> Thanks all for what Grails as become so far - it's helped me at work a lot
> the past
> few weeks and I'm digging what I'm learning!
>
> On 10/3/07, Daniel.Sun <[hidden email]> wrote:
> >
> > Hi Graeme,
> >
> > You know, using plugins can make the startup slower than before and the
> > quality of plugin will impact our app.
> > So providing the basic way to limit access or something like that will be
> > good.
> >
> > Cheers,
> > Daniel.Sun
> >
> >
>
> --
> Michael Kimsal
> http://webdevradio.com

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

graemer
In reply to this post by Marc Palmer Local
On 10/3/07, Marc Palmer <[hidden email]> wrote:

>
> On 3 Oct 2007, at 12:34, Peter Ledbrook wrote:
>
> > On 03/10/2007, Darryl Pentz <[hidden email]> wrote:
> >>
> >> I like your ideas Steven, but then I do agree with Graeme it's
> >> best included
> >> in a security plugin.
> >>
> >> Neither of the two indicated plugins are perfect unfortunately:
> >> 1. Acegi is too complex for simple access implementations
> >> 2. JSecurity currently requires a common base controller, which
> >> I'd prefer
> >> to not be required to do, since I already have a base controller,
> >> and the
> >> inheritance hierarchy becomes dodgy.
> >
> > True. The question is, do I wait for the web filter plugin, or just
> > implement one myself for the JSecurity plugin? I'm leaning towards the
> > latter now.
> >
>
> Filters are in 1.0-RC1 aren't they? Not tried but that was my
> understanding.

They haven't been committed just yet. Mike tells me he will on Thursday

Cheers

>
> Marc
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Steven Devijver
In reply to this post by Marc Palmer Local
On 10/3/07, Marc Palmer <[hidden email]> wrote:

>
> On 3 Oct 2007, at 10:57, Steven Devijver wrote:
>
> > I agree these features should be part of a security plugin.
> >
> > I think the currently proliferation of security plugins and their
> > diverging behaviors could be solved by creating a spec for security
> > attributes. Each plugin can then implement these as they see fit.
> >
> > For the Helper interfaces, again this can be a plugin. A helper
> > interface definition could be part of a future security configuration
> > spec.
> >
>
> I am not sure what use/special need the helpers are for. With plugins
> it is easy to add methods to any artefacts already using
> doWithDynamicMethods and the ExpandoMetaClass.
>
> In applications it may be possible to do this in ApplicationBootstrap
> but I think we definitely need doWithXXX happening for applications too.
>
> Marc

For me the big advantage of having interface is to say to people: you
can expect these methods to be available. I may even make IDE
integration easier.

ExpandoMetaClass would be the way to make these methods _technically_
available on certain artefacts. The interfaces are a way to make them
mentally available. It also allows people to settle on clear
contracts.

I'm not saying every dynamic method should be defined in an interface.
It's just a nice way to define a contract that's then dynamically made
available by Grails.

Just my 0.2€

Steven

>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Marc Palmer Local

On 3 Oct 2007, at 12:58, Steven Devijver wrote:

>>
>
> For me the big advantage of having interface is to say to people: you
> can expect these methods to be available. I may even make IDE
> integration easier.
>
> ExpandoMetaClass would be the way to make these methods _technically_
> available on certain artefacts. The interfaces are a way to make them
> mentally available. It also allows people to settle on clear
> contracts.
>
> I'm not saying every dynamic method should be defined in an interface.
> It's just a nice way to define a contract that's then dynamically made
> available by Grails.
>
> Just my 0.2€
>

I understand completely, but I think its a throwback to Java  
approaches :)

I tried exactly what you suggest for a plugin I wrote - I wrote an  
interface that was just effectively documenting the API objects must  
support.

But then... it was just that, documentation. You never need to  
implement it, you never need to import it - when programming  
idiomatic groovy.

So I ditched it. There's no point. Write documentation, not interfaces.

At best one should use UML or IDL to define these interfaces,  
language-neutral and without some source code that is never going to  
be used.

That's what I've found anyway, as someone who used to love interfaces  
and making concrete APIs in Java. It just doesn't make sense in  
Groovy/Grails land. Documentation does.

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

jondo_w
In reply to this post by Marc Palmer Local
If I could add to some of Marcs suggestions, it would be handy to also apply access control in the UrlMappings.groovy configuration. So you could restrict access at that level.

- DP

Marc Palmer Local wrote
This is exactly the motification behind the Grails Standard Mail  
proposal.

http://grails.org/Grails+Standard+Mail

However there is a problem with security. Messaging is messaging,  
pretty much. The concepts don't vary too much but the transports do.

Authentication and authorisation are done in many different ways. Not  
everyone likes "roles". Some people prefer ACLs, permissions and  
other approaches. It gets rather difficult to support this.

Furthermore authorisation config should be orthogonal to the code,  
rather like Filters are. In fact filters may be the best place for  
this kind of thing... i.e. some kind of:

authBy([role:'administrator'])
authBy([permission:'changeConfig'])

Where the params are a map that is passed to whatever plugin(s) are  
installed to handle authorisation. We could by default build in  
trivial role-based authorisation.

I still think this is best defined as a convention, not code, and a  
reference plugin implementation supplied, which is the concept behind  
Grails Standard Mail.

We might need a hook into the Filters DSL or similar to search for  
plugins that declare they care about authorisation. Perhaps we need a  
new plugin property:

static exposes = ['authorisation':{ impl here }]

Where common names for exposed services are published. Grails filter  
handling would look for all plugins exposing 'authorisation' when it  
hits a filter with authBy, and ask them all if they will permit the  
action or "don't know".

The advantage of this kind of thing is that it means minimal changes  
to get it into core Grails (== sooner) and then the rest is deferred  
to plugin authors.

What do you guys think about this kind of approach? Shall I knock  
together a proposal in sandbox? It will need to wait until after GEX  
because I'm rammed with work and slides and trying to get some Grails  
1.0 tasks done.


Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Marc Palmer Local

On 3 Oct 2007, at 14:47, Darryl Pentz wrote:

>
> If I could add to some of Marcs suggestions, it would be handy to  
> also apply
> access control in the UrlMappings.groovy configuration. So you could
> restrict access at that level.
>

That is the obvious place at first but then you think about it and...  
if you don't want someone to say "edit user profile" you need to stop  
-all- access to that controller, no matter what URL is used to access  
it over time.

Hence putting it in filters, which apply to controllers/actions more  
than URLs, is surely a better plan?

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Randall R Schulz
In reply to this post by Marc Palmer Local
On Wednesday 03 October 2007 06:39, Marc Palmer wrote:

> ...
>
> I tried exactly what you suggest for a plugin I wrote - I wrote an
> interface that was just effectively documenting the API objects must
> support.
>
> But then... it was just that, documentation. You never need to
> implement it, you never need to import it - when programming
> idiomatic groovy.
>
> So I ditched it. There's no point. Write documentation, not
> interfaces.

Interfaces are formal. They're a promise to client programmers and an
obligation to implementing programmers. This is a _good thing_.

Documentation has no formal semantics, no obligations of any sort.
Documentation has no force, neither when it exists nor to bring it into
existence. Need I point out how vastly underdocumented Grails is?


I think we should call dynamic programming "hope-based." You write some
code and hope it will run.


> ....
>
> Marc


Randall Schulz

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Steven Devijver
On 10/3/07, Randall R Schulz <[hidden email]> wrote:

> On Wednesday 03 October 2007 06:39, Marc Palmer wrote:
> > ...
> >
> > I tried exactly what you suggest for a plugin I wrote - I wrote an
> > interface that was just effectively documenting the API objects must
> > support.
> >
> > But then... it was just that, documentation. You never need to
> > implement it, you never need to import it - when programming
> > idiomatic groovy.
> >
> > So I ditched it. There's no point. Write documentation, not
> > interfaces.
>
> Interfaces are formal. They're a promise to client programmers and an
> obligation to implementing programmers. This is a _good thing_.
>
> Documentation has no formal semantics, no obligations of any sort.
> Documentation has no force, neither when it exists nor to bring it into
> existence. Need I point out how vastly underdocumented Grails is?
>
>
> I think we should call dynamic programming "hope-based." You write some
> code and hope it will run.
>

This helper interfaces can be implemented as a plugin, to be installed
by those who prefer.

>
> > ....
> >
> > Marc
>
>
> Randall Schulz
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Marc Palmer Local
In reply to this post by Randall R Schulz

On 3 Oct 2007, at 15:54, Randall R Schulz wrote:

> On Wednesday 03 October 2007 06:39, Marc Palmer wrote:
>> ...
>>
>> I tried exactly what you suggest for a plugin I wrote - I wrote an
>> interface that was just effectively documenting the API objects must
>> support.
>>
>> But then... it was just that, documentation. You never need to
>> implement it, you never need to import it - when programming
>> idiomatic groovy.
>>
>> So I ditched it. There's no point. Write documentation, not
>> interfaces.
>
> Interfaces are formal. They're a promise to client programmers and an
> obligation to implementing programmers. This is a _good thing_.
>

Actually, I think I disagree. Please understand I come from a long  
history of loving interfaces :)

Here's my line of thinking.

Interfaces are formal: So is a detailed specification via UML or IDL.

Promise to programmers: So is a detailed spec. An implementation of  
an interface OR an implementation of a spec can be badly written. In  
fact I would say that most (Java source) interfaces are mis-
implemented by many people! Where do you refer to for the -exact-  
definition of behaviour? The specification. I cite... Servlets  
specification, J2ME APIs etc

This is a good thing: YES! But interfaces defined in source code give  
you no extra guarantees about anything. They just enforce this:

1) The user adds implements X to their code
2) Method signatures (not behaviour) match the interface at compile  
time.

Any failures in functionality (that's the actual promise to  
programmers) will still occur at runtime as they would if you did not  
define an interface.

> Documentation has no formal semantics, no obligations of any sort.
> Documentation has no force, neither when it exists nor to bring it  
> into
> existence. Need I point out how vastly underdocumented Grails is?
>
This is not true. UML and IDL have formal semantics, don't they? IDL  
is the language-neutral interface definition language for CORBA but  
is a general purpose IDL. UML, if sufficiently detailed, can act as  
the same.

Detail is what's needed, and a stamp of "This is how Grails does it -  
deviate and you will suffer!"

>
> I think we should call dynamic programming "hope-based." You write  
> some
> code and hope it will run.
>

In some respects this is true, and this is exactly what I said when I  
started using Groovy and Grails. The answer is of course unit testing  
- its the only way for dynamic languages.

Interfaces may give a false sense of security. They just make sure  
you're calling methods that exist with parameters of certain types.  
They offer absolutely NO guarantees about the underlying functionality.

These days I feel that if I'm going to use a dynamic language at all,  
I should use it fully and throw my old static typing concerns out of  
the window (except when coding Java of course!). Once I did this,  
everything got much easier and more fun :)

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Fusebox ideas

Marc Palmer Local
In reply to this post by Steven Devijver

On 3 Oct 2007, at 16:10, Steven Devijver wrote:

> On 10/3/07, Randall R Schulz <[hidden email]> wrote:
>> On Wednesday 03 October 2007 06:39, Marc Palmer wrote:
>>> ...
>>>
>>> I tried exactly what you suggest for a plugin I wrote - I wrote an
>>> interface that was just effectively documenting the API objects must
>>> support.
>>>
>>> But then... it was just that, documentation. You never need to
>>> implement it, you never need to import it - when programming
>>> idiomatic groovy.
>>>
>>> So I ditched it. There's no point. Write documentation, not
>>> interfaces.
>>
>> Interfaces are formal. They're a promise to client programmers and an
>> obligation to implementing programmers. This is a _good thing_.
>>
>> Documentation has no formal semantics, no obligations of any sort.
>> Documentation has no force, neither when it exists nor to bring it  
>> into
>> existence. Need I point out how vastly underdocumented Grails is?
>>
>>
>> I think we should call dynamic programming "hope-based." You write  
>> some
>> code and hope it will run.
>>
>
> This helper interfaces can be implemented as a plugin, to be installed
> by those who prefer.
>

Perfect :)

Marc


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

12