Date: Mon, 9 Apr 2012 20:54:28 -0700 (PDT) From: "@CapedCoder" <cfx...@gmail.com> To: framework-one@googlegroups.com Message-ID: <4280206.1365.1334030068352.JavaMail.geo-discussion-forums@vbxy18> In-Reply-To: <CANdw0Ff=1WcmYSjfzhNuDdrKUk6LFXhvv0zmAkaL3o4_ZiubSA@mail.gmail.com> References: <29459378.687.1334021238282.JavaMail.geo-discussion-forums@vbhy1> <CANdw0Ff=1WcmYSjfzhNuDdrKUk6LFXhvv0zmAkaL3o4_ZiubSA@mail.gmail.com> Subject: Re: [framework-one] Thoughts on Securing an Application MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1363_14727037.1334030068347" ------=_Part_1363_14727037.1334030068347 Content-Type: multipart/alternative; boundary="----=_Part_1364_19821067.1334030068348" ------=_Part_1364_19821067.1334030068348 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Excellent idea on caching the metadata, that should negate a great deal of the performance impact I would expect. You're absolutely right about locking into a particular model for security. We all know that once our employers find out what kind of rock stars we are they want us to continue expanding the applications beyond what they originally intended (and often they change them before we're even done). I have experimented with a variety of methods, most of which seem to become extremely verbose eventually as you add additional conditional logic (remember, you're a rock star). Currently I am just looking to lock down bits and pieces of a custom CMS system, I doubt it will expand much further than that but it would be job security if it does. It would be great to put together a common security plugin for FW/1 so that we all don't have to reinvent the wheel. Seth On Monday, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wrote: > The one concern I'd have before locking into this scheme is that > you're setting up a world where there is a one-to-one relationship > between a controller action and your security model. It may be that as > you go you find that a single controller method is used in different > authentication contexts (by different user types in different ways). > If you have good reason to believe that won't be case or are > comfortable just baking in that assumption then seems fine, on face. > > In general, I think going with meta data should save you a decent > amount of coding, but in this case I'm not sure it really does -- you > still need to type in the roles and the extra attribute, which isn't > less code to maintain than just calling a method from your base > controller to secure a given controller action. You DO get the > benefit of automatic documentation and a tight idiom, so those might > be good enough reasons in your case. > > Be sure to cache the meta data in the init() of your base controller, > so you're not incurring the overhead of that every time you want to > look it up. > > I find that I now always use a baseController for all of my > controllers -- it's quite slim in most cases, but it has been nice to > be able to have some utility methods always available (and I grab a > lookup of my services in the init, so I can reference them in my > controller methods as simply "services.myService.myMethod(myArgs)" > instead of calling out to the bean factory every time), so remembering > to do the super.before(rc) doesn't seem too onerous. > > As an aside, I've been thinking about what a "plugin" system for FW/1 > would look like lately, and this might be an interesting candidate -- > basically a way to, by convention, have your machinery called as part > of the before()/init() of a controller call. I've been building a > bunch of "small" apps lately, and all of them have basically the same > user/permissions setup and some basic utilities for doing things like > bootstrapping various versions of the app as it goes through > deployments -- but I end up copying/pasting a lot of that into the > various nooks and crannies of FW/1 instead of having it all as a nice > bundle of code. Subsystems don't quite work for this kind of thing > from my initial noodling, though. > > - Nathan Dintenfass > > On Mon, Apr 9, 2012 at 6:27 PM, @CapedCoder <> wrote: > > Hi All, > > > > I'm looking for some feedback on implementing security in my application. > > > > What I was thinking of doing is adding an annotation of > permissions="myrole" > > to those methods I want to secure in my controllers. I would then extend > > each of my controllers that have "secure" methods with a base controller > in > > which the before() method would inspect the metadata for the method in > the > > cfc that I am calling e.g. startManageArticles. If the particular method > > has a "permissions" property it would compare that property against their > > array of permissions and redirect them to another page if it does not > > exist. The only caveat I have found is that if I want my target > controller > > to have a before() function, I have to call super.before(rc) in order to > > enforce the security. I have tested this and it does work, but I'm not > sure > > if it is good practice. > > > > I'm interested in hearing how other folks have addressed this common > problem > > and whether or not this may be a good way to solve this problem. > > > > Thanks! > > > > Seth > > @capedcoder > > > > > > > > -- > > FW/1 on RIAForge: http://fw1.riaforge.org/ > > > > FW/1 on github: http://github.com/seancorfield/fw1 > > > > FW/1 on Google Groups: http://groups.google.com/group/framework-one > > On Monday, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wrote: > > The one concern I'd have before locking into this scheme is that > you're setting up a world where there is a one-to-one relationship > between a controller action and your security model. It may be that as > you go you find that a single controller method is used in different > authentication contexts (by different user types in different ways). > If you have good reason to believe that won't be case or are > comfortable just baking in that assumption then seems fine, on face. > > In general, I think going with meta data should save you a decent > amount of coding, but in this case I'm not sure it really does -- you > still need to type in the roles and the extra attribute, which isn't > less code to maintain than just calling a method from your base > controller to secure a given controller action. You DO get the > benefit of automatic documentation and a tight idiom, so those might > be good enough reasons in your case. > > Be sure to cache the meta data in the init() of your base controller, > so you're not incurring the overhead of that every time you want to > look it up. > > I find that I now always use a baseController for all of my > controllers -- it's quite slim in most cases, but it has been nice to > be able to have some utility methods always available (and I grab a > lookup of my services in the init, so I can reference them in my > controller methods as simply "services.myService.myMethod(myArgs)" > instead of calling out to the bean factory every time), so remembering > to do the super.before(rc) doesn't seem too onerous. > > As an aside, I've been thinking about what a "plugin" system for FW/1 > would look like lately, and this might be an interesting candidate -- > basically a way to, by convention, have your machinery called as part > of the before()/init() of a controller call. I've been building a > bunch of "small" apps lately, and all of them have basically the same > user/permissions setup and some basic utilities for doing things like > bootstrapping various versions of the app as it goes through > deployments -- but I end up copying/pasting a lot of that into the > various nooks and crannies of FW/1 instead of having it all as a nice > bundle of code. Subsystems don't quite work for this kind of thing > from my initial noodling, though. > > - Nathan Dintenfass > > On Mon, Apr 9, 2012 at 6:27 PM, @CapedCoder <> wrote: > > Hi All, > > > > I'm looking for some feedback on implementing security in my application. > > > > What I was thinking of doing is adding an annotation of > permissions="myrole" > > to those methods I want to secure in my controllers. I would then extend > > each of my controllers that have "secure" methods with a base controller > in > > which the before() method would inspect the metadata for the method in > the > > cfc that I am calling e.g. startManageArticles. If the particular method > > has a "permissions" property it would compare that property against their > > array of permissions and redirect them to another page if it does not > > exist. The only caveat I have found is that if I want my target > controller > > to have a before() function, I have to call super.before(rc) in order to > > enforce the security. I have tested this and it does work, but I'm not > sure > > if it is good practice. > > > > I'm interested in hearing how other folks have addressed this common > problem > > and whether or not this may be a good way to solve this problem. > > > > Thanks! > > > > Seth > > @capedcoder > > > > > > > > -- > > FW/1 on RIAForge: http://fw1.riaforge.org/ > > > > FW/1 on github: http://github.com/seancorfield/fw1 > > > > FW/1 on Google Groups: http://groups.google.com/group/framework-one > > On Monday, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wrote: > > The one concern I'd have before locking into this scheme is that > you're setting up a world where there is a one-to-one relationship > between a controller action and your security model. It may be that as > you go you find that a single controller method is used in different > authentication contexts (by different user types in different ways). > If you have good reason to believe that won't be case or are > comfortable just baking in that assumption then seems fine, on face. > > In general, I think going with meta data should save you a decent > amount of coding, but in this case I'm not sure it really does -- you > still need to type in the roles and the extra attribute, which isn't > less code to maintain than just calling a method from your base > controller to secure a given controller action. You DO get the > benefit of automatic documentation and a tight idiom, so those might > be good enough reasons in your case. > > Be sure to cache the meta data in the init() of your base controller, > so you're not incurring the overhead of that every time you want to > look it up. > > I find that I now always use a baseController for all of my > controllers -- it's quite slim in most cases, but it has been nice to > be able to have some utility methods always available (and I grab a > lookup of my services in the init, so I can reference them in my > controller methods as simply "services.myService.myMethod(myArgs)" > instead of calling out to the bean factory every time), so remembering > to do the super.before(rc) doesn't seem too onerous. > > As an aside, I've been thinking about what a "plugin" system for FW/1 > would look like lately, and this might be an interesting candidate -- > basically a way to, by convention, have your machinery called as part > of the before()/init() of a controller call. I've been building a > bunch of "small" apps lately, and all of them have basically the same > user/permissions setup and some basic utilities for doing things like > bootstrapping various versions of the app as it goes through > deployments -- but I end up copying/pasting a lot of that into the > various nooks and crannies of FW/1 instead of having it all as a nice > bundle of code. Subsystems don't quite work for this kind of thing > from my initial noodling, though. > > - Nathan Dintenfass > > On Mon, Apr 9, 2012 at 6:27 PM, @CapedCoder <> wrote: > > Hi All, > > > > I'm looking for some feedback on implementing security in my application. > > > > What I was thinking of doing is adding an annotation of > permissions="myrole" > > to those methods I want to secure in my controllers. I would then extend > > each of my controllers that have "secure" methods with a base controller > in > > which the before() method would inspect the metadata for the method in > the > > cfc that I am calling e.g. startManageArticles. If the particular method > > has a "permissions" property it would compare that property against their > > array of permissions and redirect them to another page if it does not > > exist. The only caveat I have found is that if I want my target > controller > > to have a before() function, I have to call super.before(rc) in order to > > enforce the security. I have tested this and it does work, but I'm not > sure > > if it is good practice. > > > > I'm interested in hearing how other folks have addressed this common > problem > > and whether or not this may be a good way to solve this problem. > > > > Thanks! > > > > Seth > > @capedcoder > > > > > > > > -- > > FW/1 on RIAForge: http://fw1.riaforge.org/ > > > > FW/1 on github: http://github.com/seancorfield/fw1 > > > > FW/1 on Google Groups: http://groups.google.com/group/framework-one > > On Monday, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wrote: > > The one concern I'd have before locking into this scheme is that > you're setting up a world where there is a one-to-one relationship > between a controller action and your security model. It may be that as > you go you find that a single controller method is used in different > authentication contexts (by different user types in different ways). > If you have good reason to believe that won't be case or are > comfortable just baking in that assumption then seems fine, on face. > > In general, I think going with meta data should save you a decent > amount of coding, but in this case I'm not sure it really does -- you > still need to type in the roles and the extra attribute, which isn't > less code to maintain than just calling a method from your base > controller to secure a given controller action. You DO get the > benefit of automatic documentation and a tight idiom, so those might > be good enough reasons in your case. > > Be sure to cache the meta data in the init() of your base controller, > so you're not incurring the overhead of that every time you want to > look it up. > > I find that I now always use a baseController for all of my > controllers -- it's quite slim in most cases, but it has been nice to > be able to have some utility methods always available (and I grab a > lookup of my services in the init, so I can reference them in my > controller methods as simply "services.myService.myMethod(myArgs)" > instead of calling out to the bean factory every time), so remembering > to do the super.before(rc) doesn't seem too onerous. > > As an aside, I've been thinking about what a "plugin" system for FW/1 > would look like lately, and this might be an interesting candidate -- > basically a way to, by convention, have your machinery called as part > of the before()/init() of a controller call. I've been building a > bunch of "small" apps lately, and all of them have basically the same > user/permissions setup and some basic utilities for doing things like > bootstrapping various versions of the app as it goes through > deployments -- but I end up copying/pasting a lot of that into the > various nooks and crannies of FW/1 instead of having it all as a nice > bundle of code. Subsystems don't quite work for this kind of thing > from my initial noodling, though. > > - Nathan Dintenfass > > On Mon, Apr 9, 2012 at 6:27 PM, @CapedCoder wrote: > > Hi All, > > > > I'm looking for some feedback on implementing security in my application. > > > > What I was thinking of doing is adding an annotation of > permissions="myrole" > > to those methods I want to secure in my controllers. I would then extend > > each of my controllers that have "secure" methods with a base controller > in > > which the before() method would inspect the metadata for the method in > the > > cfc that I am calling e.g. startManageArticles. If the particular method > > has a "permissions" property it would compare that property against their > > array of permissions and redirect them to another page if it does not > > exist. The only caveat I have found is that if I want my target > controller > > to have a before() function, I have to call super.before(rc) in order to > > enforce the security. I have tested this and it does work, but I'm not > sure > > if it is good practice. > > > > I'm interested in hearing how other folks have addressed this common > problem > > and whether or not this may be a good way to solve this problem. > > > > Thanks! > > > > Seth > > @capedcoder > > > > > > > > -- > > FW/1 on RIAForge: http://fw1.riaforge.org/ > > > > FW/1 on github: http://github.com/seancorfield/fw1 > > > > FW/1 on Google Groups: http://groups.google.com/group/framework-one > > On Monday, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wrote: > > The one concern I'd have before locking into this scheme is that > you're setting up a world where there is a one-to-one relationship > between a controller action and your security model. It may be that as > you go you find that a single controller method is used in different > authentication contexts (by different user types in different ways). > If you have good reason to believe that won't be case or are > comfortable just baking in that assumption then seems fine, on face. > > In general, I think going with meta data should save you a decent > amount of coding, but in this case I'm not sure it really does -- you > still need to type in the roles and the extra attribute, which isn't > less code to maintain than just calling a method from your base > controller to secure a given controller action. You DO get the > benefit of automatic documentation and a tight idiom, so those might > be good enough reasons in your case. > > Be sure to cache the meta data in the init() of your base controller, > so you're not incurring the overhead of that every time you want to > look it up. > > I find that I now always use a baseController for all of my > controllers -- it's quite slim in most cases, but it has been nice to > be able to have some utility methods always available (and I grab a > lookup of my services in the init, so I can reference them in my > controller methods as simply "services.myService.myMethod(myArgs)" > instead of calling out to the bean factory every time), so remembering > to do the super.before(rc) doesn't seem too onerous. > > As an aside, I've been thinking about what a "plugin" system for FW/1 > would look like lately, and this might be an interesting candidate -- > basically a way to, by convention, have your machinery called as part > of the before()/init() of a controller call. I've been building a > bunch of "small" apps lately, and all of them have basically the same > user/permissions setup and some basic utilities for doing things like > bootstrapping various versions of the app as it goes through > deployments -- but I end up copying/pasting a lot of that into the > various nooks and crannies of FW/1 instead of having it all as a nice > bundle of code. Subsystems don't quite work for this kind of thing > from my initial noodling, though. > > - Nathan Dintenfass > > On Mon, Apr 9, 2012 at 6:27 PM, @CapedCoder wrote: > > Hi All, > > > > I'm looking for some feedback on implementing security in my application. > > > > What I was thinking of doing is adding an annotation of > permissions="myrole" > > to those methods I want to secure in my controllers. I would then extend > > each of my controllers that have "secure" methods with a base controller > in > > which the before() method would inspect the metadata for the method in > the > > cfc that I am calling e.g. startManageArticles. If the particular method > > has a "permissions" property it would compare that property against their > > array of permissions and redirect them to another page if it does not > > exist. The only caveat I have found is that if I want my target > controller > > to have a before() function, I have to call super.before(rc) in order to > > enforce the security. I have tested this and it does work, but I'm not > sure > > if it is good practice. > > > > I'm interested in hearing how other folks have addressed this common > problem > > and whether or not this may be a good way to solve this problem. > > > > Thanks! > > > > Seth > > @capedcoder > > > > > > > > -- > > FW/1 on RIAForge: http://fw1.riaforge.org/ > > > > FW/1 on github: http://github.com/seancorfield/fw1 > > > > FW/1 on Google Groups: http://groups.google.com/group/framework-one > > ------=_Part_1364_19821067.1334030068348 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <div>Excellent idea on caching the metadata, that should negate a great dea= l of the performance impact I would expect. You're absolutely right a= bout locking into a particular model for security. We all know that o= nce our employers find out what kind of rock stars we are they want us to c= ontinue expanding the applications beyond what they originally intended (an= d often they change them before we're even done). I have experimented= with a variety of methods, most of which seem to become extremely ver= bose eventually as you add additional conditional logic (remember, you're a= rock star). Currently I am just looking to lock down bits and pieces= of a custom CMS system, I doubt it will expand much further than that but = it would be job security if it does. It would be great to put togethe= r a common security plugin for FW/1 so that we all don't have to reinv= ent the wheel. </div><div> </div><div>Seth</div><div><br>On Mond= ay, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wrote:</div><blockquote st= yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb= (204, 204, 204); border-left-width: 1px; border-left-style: solid;" class= =3D"gmail_quote">The one concern I'd have before locking into this scheme i= s that<br>you're setting up a world where there is a one-to-one relationshi= p<br>between a controller action and your security model. It may be that as= <br>you go you find that a single controller method is used in different<br= >authentication contexts (by different user types in different ways).<br>If= you have good reason to believe that won't be case or are<br>comfortable j= ust baking in that assumption then seems fine, on face.<p>In general, I thi= nk going with meta data should save you a decent<br>amount of coding, but i= n this case I'm not sure it really does -- you<br>still need to type in the= roles and the extra attribute, which isn't<br>less code to maintain than j= ust calling a method from your base<br>controller to secure a given control= ler action. You DO get the<br>benefit of automatic documentation and = a tight idiom, so those might<br>be good enough reasons in your case.<p>Be = sure to cache the meta data in the init() of your base controller,<br>so yo= u're not incurring the overhead of that every time you want to<br>look it u= p.<p>I find that I now always use a baseController for all of my<br>control= lers -- it's quite slim in most cases, but it has been nice to<br>be able t= o have some utility methods always available (and I grab a<br>lookup of my = services in the init, so I can reference them in my<br>controller methods a= s simply "services.myService.myMethod(<wbr>myArgs)"<br>instead of calling o= ut to the bean factory every time), so remembering<br>to do the super.befor= e(rc) doesn't seem too onerous.<p>As an aside, I've been thinking about wha= t a "plugin" system for FW/1<br>would look like lately, and this might be a= n interesting candidate --<br>basically a way to, by convention, have your = machinery called as part<br>of the before()/init() of a controller call. I'= ve been building a<br>bunch of "small" apps lately, and all of them have ba= sically the same<br>user/permissions setup and some basic utilities for doi= ng things like<br>bootstrapping various versions of the app as it goes thro= ugh<br>deployments -- but I end up copying/pasting a lot of that into the<b= r>various nooks and crannies of FW/1 instead of having it all as a nice<br>= bundle of code. Subsystems don't quite work for this kind of thing<br= >from my initial noodling, though.<p> - Nathan Dintenfass<p><p>On Mon,= Apr 9, 2012 at 6:27 PM, @CapedCoder <> wrote:<br>> Hi All,<br>>= ;<br>> I'm looking for some feedback on implementing security in my= application.<br>><br>> What I was thinking of doing is adding an&nbs= p;annotation of permissions=3D"myrole"<br>> to those methods I want to s= ecure in my controllers. I would then extend<br>> each of my = controllers that have "secure" methods with a base controller in<br>&g= t; which the before() method would inspect the metadata for the m= ethod in the<br>> cfc that I am calling e.g. startManageArticles.&n= bsp; If the particular method<br>> has a "permissions" property it would= compare that property against their<br>> array of permissions and redir= ect them to another page if it does not<br>> exist. The only = caveat I have found is that if I want my target controller<br>> to = have a before() function, I have to call super.before(rc) in order to<br>&g= t; enforce the security. I have tested this and it does work, but I'm= not sure<br>> if it is good practice.<br>><br>> I'm interested in= hearing how other folks have addressed this common problem<br>> and whe= ther or not this may be a good way to solve this problem.<br>><br>> T= hanks!<br>><br>> Seth<br>> @capedcoder<br>><br>><br>><br>= > --<br>> FW/1 on RIAForge: <a href=3D"http://fw1.riaforge.org/" targ= et=3D"_blank">http://fw1.riaforge.org/</a><br>><br>> FW/1 on github: = <a href=3D"http://github.com/seancorfield/fw1" target=3D"_blank">http://git= hub.com/<wbr>seancorfield/fw1</a><br>><br>> FW/1 on Google Groups: <a= href=3D"http://groups.google.com/group/framework-one" target=3D"_blank">ht= tp://groups.google.com/<wbr>group/framework-one</a><br></p><p></p><p></p><p= ></p><p></p><p></p><p></p></blockquote><br>On Monday, April 9, 2012 11:23:3= 6 PM UTC-4, ndintenfass wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8e= x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi= dth: 1px; border-left-style: solid;" class=3D"gmail_quote">The one concern = I'd have before locking into this scheme is that<br>you're setting up a wor= ld where there is a one-to-one relationship<br>between a controller action = and your security model. It may be that as<br>you go you find that a single= controller method is used in different<br>authentication contexts (by diff= erent user types in different ways).<br>If you have good reason to believe = that won't be case or are<br>comfortable just baking in that assumption the= n seems fine, on face.<p>In general, I think going with meta data should sa= ve you a decent<br>amount of coding, but in this case I'm not sure it reall= y does -- you<br>still need to type in the roles and the extra attribute, w= hich isn't<br>less code to maintain than just calling a method from your ba= se<br>controller to secure a given controller action. You DO get the<= br>benefit of automatic documentation and a tight idiom, so those might<br>= be good enough reasons in your case.<p>Be sure to cache the meta data in th= e init() of your base controller,<br>so you're not incurring the overhead o= f that every time you want to<br>look it up.<p>I find that I now always use= a baseController for all of my<br>controllers -- it's quite slim in most c= ases, but it has been nice to<br>be able to have some utility methods alway= s available (and I grab a<br>lookup of my services in the init, so I can re= ference them in my<br>controller methods as simply "services.myService.myMe= thod(<wbr>myArgs)"<br>instead of calling out to the bean factory every time= ), so remembering<br>to do the super.before(rc) doesn't seem too onerous.<p= >As an aside, I've been thinking about what a "plugin" system for FW/1<br>w= ould look like lately, and this might be an interesting candidate --<br>bas= ically a way to, by convention, have your machinery called as part<br>of th= e before()/init() of a controller call. I've been building a<br>bunch of "s= mall" apps lately, and all of them have basically the same<br>user/permissi= ons setup and some basic utilities for doing things like<br>bootstrapping v= arious versions of the app as it goes through<br>deployments -- but I end u= p copying/pasting a lot of that into the<br>various nooks and crannies of F= W/1 instead of having it all as a nice<br>bundle of code. Subsystems = don't quite work for this kind of thing<br>from my initial noodling, though= .<p> - Nathan Dintenfass<p><p>On Mon, Apr 9, 2012 at 6:27 PM, @CapedCo= der <> wrote:<br>> Hi All,<br>><br>> I'm looking for some fe= edback on implementing security in my application.<br>><br>> Wha= t I was thinking of doing is adding an annotation of permissions=3D"my= role"<br>> to those methods I want to secure in my controllers. &nb= sp;I would then extend<br>> each of my controllers that have "secure" me= thods with a base controller in<br>> which the before() method woul= d inspect the metadata for the method in the<br>> cfc tha= t I am calling e.g. startManageArticles. If the particular method<br>= > has a "permissions" property it would compare that property against th= eir<br>> array of permissions and redirect them to another page if it do= es not<br>> exist. The only caveat I have found is that = if I want my target controller<br>> to have a before() function, I have = to call super.before(rc) in order to<br>> enforce the security. I = have tested this and it does work, but I'm not sure<br>> if it is good p= ractice.<br>><br>> I'm interested in hearing how other folks have add= ressed this common problem<br>> and whether or not this may be a good wa= y to solve this problem.<br>><br>> Thanks!<br>><br>> Seth<br>&g= t; @capedcoder<br>><br>><br>><br>> --<br>> FW/1 on RIAForge:= <a href=3D"http://fw1.riaforge.org/" target=3D"_blank">http://fw1.riaforge= .org/</a><br>><br>> FW/1 on github: <a href=3D"http://github.com/sean= corfield/fw1" target=3D"_blank">http://github.com/<wbr>seancorfield/fw1</a>= <br>><br>> FW/1 on Google Groups: <a href=3D"http://groups.google.com= /group/framework-one" target=3D"_blank">http://groups.google.com/<wbr>group= /framework-one</a><br></p><p></p><p></p><p></p><p></p><p></p><p></p></block= quote><br>On Monday, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wrote:<bl= ockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left= -color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: soli= d;" class=3D"gmail_quote">The one concern I'd have before locking into this= scheme is that<br>you're setting up a world where there is a one-to-one re= lationship<br>between a controller action and your security model. It may b= e that as<br>you go you find that a single controller method is used in dif= ferent<br>authentication contexts (by different user types in different way= s).<br>If you have good reason to believe that won't be case or are<br>comf= ortable just baking in that assumption then seems fine, on face.<p>In gener= al, I think going with meta data should save you a decent<br>amount of codi= ng, but in this case I'm not sure it really does -- you<br>still need to ty= pe in the roles and the extra attribute, which isn't<br>less code to mainta= in than just calling a method from your base<br>controller to secure a give= n controller action. You DO get the<br>benefit of automatic documenta= tion and a tight idiom, so those might<br>be good enough reasons in your ca= se.<p>Be sure to cache the meta data in the init() of your base controller,= <br>so you're not incurring the overhead of that every time you want to<br>= look it up.<p>I find that I now always use a baseController for all of my<b= r>controllers -- it's quite slim in most cases, but it has been nice to<br>= be able to have some utility methods always available (and I grab a<br>look= up of my services in the init, so I can reference them in my<br>controller = methods as simply "services.myService.myMethod(<wbr>myArgs)"<br>instead of = calling out to the bean factory every time), so remembering<br>to do the su= per.before(rc) doesn't seem too onerous.<p>As an aside, I've been thinking = about what a "plugin" system for FW/1<br>would look like lately, and this m= ight be an interesting candidate --<br>basically a way to, by convention, h= ave your machinery called as part<br>of the before()/init() of a controller= call. I've been building a<br>bunch of "small" apps lately, and all of the= m have basically the same<br>user/permissions setup and some basic utilitie= s for doing things like<br>bootstrapping various versions of the app as it = goes through<br>deployments -- but I end up copying/pasting a lot of that i= nto the<br>various nooks and crannies of FW/1 instead of having it all as a= nice<br>bundle of code. Subsystems don't quite work for this kind of= thing<br>from my initial noodling, though.<p> - Nathan Dintenfass<p><= p>On Mon, Apr 9, 2012 at 6:27 PM, @CapedCoder <> wrote:<br>> Hi Al= l,<br>><br>> I'm looking for some feedback on implementing secur= ity in my application.<br>><br>> What I was thinking of doing is addi= ng an annotation of permissions=3D"myrole"<br>> to those methods I = want to secure in my controllers. I would then extend<br>> ea= ch of my controllers that have "secure" methods with a base controller= in<br>> which the before() method would inspect the metadata = for the method in the<br>> cfc that I am calling e.g. startManageAr= ticles. If the particular method<br>> has a "permissions" property= it would compare that property against their<br>> array of permissions = and redirect them to another page if it does not<br>> exist. = The only caveat I have found is that if I want my target controller<br= >> to have a before() function, I have to call super.before(rc) in order= to<br>> enforce the security. I have tested this and it does work= , but I'm not sure<br>> if it is good practice.<br>><br>> I'm inte= rested in hearing how other folks have addressed this common problem<br>>= ; and whether or not this may be a good way to solve this problem.<br>><= br>> Thanks!<br>><br>> Seth<br>> @capedcoder<br>><br>><br= >><br>> --<br>> FW/1 on RIAForge: <a href=3D"http://fw1.riaforge.o= rg/" target=3D"_blank">http://fw1.riaforge.org/</a><br>><br>> FW/1 on= github: <a href=3D"http://github.com/seancorfield/fw1" target=3D"_blank">h= ttp://github.com/<wbr>seancorfield/fw1</a><br>><br>> FW/1 on Google G= roups: <a href=3D"http://groups.google.com/group/framework-one" target=3D"_= blank">http://groups.google.com/<wbr>group/framework-one</a><br></p><p></p>= <p></p><p></p><p></p><p></p><p></p></blockquote><br>On Monday, April 9, 201= 2 11:23:36 PM UTC-4, ndintenfass wrote:<blockquote style=3D"margin: 0px 0px= 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde= r-left-width: 1px; border-left-style: solid;" class=3D"gmail_quote">The one= concern I'd have before locking into this scheme is that<br>you're setting= up a world where there is a one-to-one relationship<br>between a controlle= r action and your security model. It may be that as<br>you go you find that= a single controller method is used in different<br>authentication contexts= (by different user types in different ways).<br>If you have good reason to= believe that won't be case or are<br>comfortable just baking in that assum= ption then seems fine, on face.<p>In general, I think going with meta data = should save you a decent<br>amount of coding, but in this case I'm not sure= it really does -- you<br>still need to type in the roles and the extra att= ribute, which isn't<br>less code to maintain than just calling a method fro= m your base<br>controller to secure a given controller action. You DO= get the<br>benefit of automatic documentation and a tight idiom, so those = might<br>be good enough reasons in your case.<p>Be sure to cache the meta d= ata in the init() of your base controller,<br>so you're not incurring the o= verhead of that every time you want to<br>look it up.<p>I find that I now a= lways use a baseController for all of my<br>controllers -- it's quite slim = in most cases, but it has been nice to<br>be able to have some utility meth= ods always available (and I grab a<br>lookup of my services in the init, so= I can reference them in my<br>controller methods as simply "services.mySer= vice.myMethod(<wbr>myArgs)"<br>instead of calling out to the bean factory e= very time), so remembering<br>to do the super.before(rc) doesn't seem too o= nerous.<p>As an aside, I've been thinking about what a "plugin" system for = FW/1<br>would look like lately, and this might be an interesting candidate = --<br>basically a way to, by convention, have your machinery called as part= <br>of the before()/init() of a controller call. I've been building a<br>bu= nch of "small" apps lately, and all of them have basically the same<br>user= /permissions setup and some basic utilities for doing things like<br>bootst= rapping various versions of the app as it goes through<br>deployments -- bu= t I end up copying/pasting a lot of that into the<br>various nooks and cran= nies of FW/1 instead of having it all as a nice<br>bundle of code. Su= bsystems don't quite work for this kind of thing<br>from my initial noodlin= g, though.<p> - Nathan Dintenfass<p><p>On Mon, Apr 9, 2012 at 6:27 PM,= @CapedCoder wrote:<br>> Hi All,<br>><br>> I'm looking for s= ome feedback on implementing security in my application.<br>><br>&g= t; What I was thinking of doing is adding an annotation of permissions= =3D"myrole"<br>> to those methods I want to secure in my controllers.&nb= sp; I would then extend<br>> each of my controllers that have "secu= re" methods with a base controller in<br>> which the before() metho= d would inspect the metadata for the method in the<br>> cfc&nb= sp;that I am calling e.g. startManageArticles. If the particular meth= od<br>> has a "permissions" property it would compare that property agai= nst their<br>> array of permissions and redirect them to another page if= it does not<br>> exist. The only caveat I have found is= that if I want my target controller<br>> to have a before() function, I= have to call super.before(rc) in order to<br>> enforce the security.&nb= sp; I have tested this and it does work, but I'm not sure<br>> if it is = good practice.<br>><br>> I'm interested in hearing how other folks ha= ve addressed this common problem<br>> and whether or not this may be a g= ood way to solve this problem.<br>><br>> Thanks!<br>><br>> Seth= <br>> @capedcoder<br>><br>><br>><br>> --<br>> FW/1 on RIA= Forge: <a href=3D"http://fw1.riaforge.org/" target=3D"_blank">http://fw1.ri= aforge.org/</a><br>><br>> FW/1 on github: <a href=3D"http://github.co= m/seancorfield/fw1" target=3D"_blank">http://github.com/<wbr>seancorfield/f= w1</a><br>><br>> FW/1 on Google Groups: <a href=3D"http://groups.goog= le.com/group/framework-one" target=3D"_blank">http://groups.google.com/<wbr= >group/framework-one</a><br></p><p></p><p></p><p></p><p></p><p></p><p></p><= /blockquote><br>On Monday, April 9, 2012 11:23:36 PM UTC-4, ndintenfass wro= te:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; borde= r-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style= : solid;" class=3D"gmail_quote">The one concern I'd have before locking int= o this scheme is that<br>you're setting up a world where there is a one-to-= one relationship<br>between a controller action and your security model. It= may be that as<br>you go you find that a single controller method is used = in different<br>authentication contexts (by different user types in differe= nt ways).<br>If you have good reason to believe that won't be case or are<b= r>comfortable just baking in that assumption then seems fine, on face.<p>In= general, I think going with meta data should save you a decent<br>amount o= f coding, but in this case I'm not sure it really does -- you<br>still need= to type in the roles and the extra attribute, which isn't<br>less code to = maintain than just calling a method from your base<br>controller to secure = a given controller action. You DO get the<br>benefit of automatic doc= umentation and a tight idiom, so those might<br>be good enough reasons in y= our case.<p>Be sure to cache the meta data in the init() of your base contr= oller,<br>so you're not incurring the overhead of that every time you want = to<br>look it up.<p>I find that I now always use a baseController for all o= f my<br>controllers -- it's quite slim in most cases, but it has been nice = to<br>be able to have some utility methods always available (and I grab a<b= r>lookup of my services in the init, so I can reference them in my<br>contr= oller methods as simply "services.myService.myMethod(<wbr>myArgs)"<br>inste= ad of calling out to the bean factory every time), so remembering<br>to do = the super.before(rc) doesn't seem too onerous.<p>As an aside, I've been thi= nking about what a "plugin" system for FW/1<br>would look like lately, and = this might be an interesting candidate --<br>basically a way to, by convent= ion, have your machinery called as part<br>of the before()/init() of a cont= roller call. I've been building a<br>bunch of "small" apps lately, and all = of them have basically the same<br>user/permissions setup and some basic ut= ilities for doing things like<br>bootstrapping various versions of the app = as it goes through<br>deployments -- but I end up copying/pasting a lot of = that into the<br>various nooks and crannies of FW/1 instead of having it al= l as a nice<br>bundle of code. Subsystems don't quite work for this k= ind of thing<br>from my initial noodling, though.<p> - Nathan Dintenfa= ss<p><p>On Mon, Apr 9, 2012 at 6:27 PM, @CapedCoder wrote:<br>> Hi All,<= br>><br>> I'm looking for some feedback on implementing security= in my application.<br>><br>> What I was thinking of doing is adding = an annotation of permissions=3D"myrole"<br>> to those methods I wan= t to secure in my controllers. I would then extend<br>> each = of my controllers that have "secure" methods with a base controller in= <br>> which the before() method would inspect the metadata for= the method in the<br>> cfc that I am calling e.g. startManageArtic= les. If the particular method<br>> has a "permissions" property it= would compare that property against their<br>> array of permissions and= redirect them to another page if it does not<br>> exist. The= only caveat I have found is that if I want my target controller<br>&g= t; to have a before() function, I have to call super.before(rc) in order to= <br>> enforce the security. I have tested this and it does work, b= ut I'm not sure<br>> if it is good practice.<br>><br>> I'm interes= ted in hearing how other folks have addressed this common problem<br>> a= nd whether or not this may be a good way to solve this problem.<br>><br>= > Thanks!<br>><br>> Seth<br>> @capedcoder<br>><br>><br>&g= t;<br>> --<br>> FW/1 on RIAForge: <a href=3D"http://fw1.riaforge.org/= " target=3D"_blank">http://fw1.riaforge.org/</a><br>><br>> FW/1 on gi= thub: <a href=3D"http://github.com/seancorfield/fw1" target=3D"_blank">http= ://github.com/<wbr>seancorfield/fw1</a><br>><br>> FW/1 on Google Grou= ps: <a href=3D"http://groups.google.com/group/framework-one" target=3D"_bla= nk">http://groups.google.com/<wbr>group/framework-one</a><br></p><p></p><p>= </p><p></p><p></p><p></p><p></p></blockquote> ------=_Part_1364_19821067.1334030068348-- ------=_Part_1363_14727037.1334030068347--
Message from discussion Thoughts on Securing an Application
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |