Preventing Method Injection

Is there a way to prevent Method Injection on a CFC? I have some
components that I want to stay private but they are included in a site wide
cache for performance. I discovered that I can just inject a method that
accesses the variables scope and pulls a reference to these components out
of the cache, by-passing all normal security check that I have build into
my getService() routine.

Andrew Penhorwood

Not that I’m aware, on any CFML engine.

Injected methods don’t only get to see the private variables scope, they
can modify it. Super handy in some situations, but impossible to really
lock down.On Mon, Feb 2, 2015 at 12:42 PM, Andrew Penhorwood <@Andrew_Penhorwood> wrote:

Is there a way to prevent Method Injection on a CFC? I have some
components that I want to stay private but they are included in a site wide
cache for performance. I discovered that I can just inject a method that
accesses the variables scope and pulls a reference to these components out
of the cache, by-passing all normal security check that I have build into
my getService() routine.

Andrew Penhorwood


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f743136f-8e30-4808-8b9c-cb8c41ccab38%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f743136f-8e30-4808-8b9c-cb8c41ccab38%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Ah yes I forgot Wirebox could do that :slight_smile:

Actually thinking about it, I use mixins / method injection in a few of my
unit tests.On 2 February 2015 at 19:45, Brad Wood <@Brad_Wood> wrote:

On Mon, Feb 2, 2015 at 1:33 PM, John Whish <@John_Whish> wrote:

DI uses constructor arguments or plain ol’ setters.

That’s actually not entirely true. DI and AOP engines rely on things like
injecting methods, properties, – even invoking private methods to sneak
their wares into your CFCs. My favorite style of injection with WireBox is
mixin because it’s so easy and requires little code:

component {
property name=“myService” inject=“myService”;
}

This works even without generated setters being enabled and will also
inject into the private (variables) scope. WireBox does this by injecting
some helper methods into the CFC that allow it to wire up the dependencies
from within without the need for messy boilerplate. I sort of feel sorry
for Java devs who have to write all that boilerplate to get their DI in,
but that’s what they get for choosing a language with all the overhead and
“big brother” stuff.

I suppose a lot of this discussion overlaps with the “should CFML have
interfaces” kind of discussions.

Thanks!

~Brad

ColdBox Platform Evangelist
*Ortus Solutions, Corp *

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CALbQ1omNu2UB%3DKz%3DzXyfnQyt78_m4gW0%2B8%3DSJ4_Ho5W7-yomJg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CALbQ1omNu2UB%3DKz%3DzXyfnQyt78_m4gW0%2B8%3DSJ4_Ho5W7-yomJg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

As a friend of mine would say “Yarp!”

Mark Drew> On 2 Feb 2015, at 20:21, Ryan Guill <@Ryan_Guill> wrote:

I put this in the ticket, but I would actually prefer onMemberAdded() and onMemberRemoved() which would allow it to fire any time any key is added to the object and allow us to do things such as synthesize getters and setters. I didn’t think about the return at the time, but i’m thinking have it return void and have it throw an error if you want to disallow it, rather than it seeming like it worked and failing silently - what do you think?

On Monday, February 2, 2015 at 2:15:48 PM UTC-6, Mark Drew wrote:
This sounds like a much more elegant way!

In the cfml world it would be onMethodAdded() and onMethodRemoved() which is much more in line with onMissingMethod()

I would suggest a return true to allow it?

Mark Drew

On 2 Feb 2015, at 18:59, Ryan Guill ryan...@gmail.com wrote:

Fair enough. In that case, what about implementing something similar to ruby’s method_added() and method_removed() which would allow us to programmatically handle this instead of a component wide setting?

This would allow us to protect certain members of the function but still allow others to be overridden - or protect the class completely. We could easily create a component that implements complete protection through these methods and then inherit from that component to apply that to another cfc.

I’m not necessarily against something like allowInjection=false - but would prefer a solution that we could use in other more flexible ways as well.

On Monday, February 2, 2015 at 12:40:09 PM UTC-6, Micha wrote:
in my opinion final and abstract is a design approach, so something checked when you load a component.
method injection is something happen after that, design limitations have no influence on that.
you can, for example remove a method, that was defined in an interface implemented ny a component with no problem.

Micha

On Mon, Feb 2, 2015 at 7:28 PM, Ryan Guill ryan...@gmail.com wrote:
Micha, there has been talk in the past about supporting ‘final’ components (see https://issues.jboss.org/browse/RAILO-46 and https://issues.jboss.org/browse/RAILO-45 - the latter even suggests that the functionality was added at one point? But I can’t seem to make it work if so). Could final be implied to not allow injections?

On Monday, February 2, 2015 at 12:26:20 PM UTC-6, Micha wrote:
no, sadly this is not possible, but it is for sure a great idea that is easy to implement.
Simply allow an attribute like “injection” with the component tag.
Can you please raise a ticket for this
https://bitbucket.org/lucee/lucee/issues

thx micha

On Mon, Feb 2, 2015 at 6:42 PM, Andrew Penhorwood penho...@gmail.com wrote:
Is there a way to prevent Method Injection on a CFC? I have some components that I want to stay private but they are included in a site wide cache for performance. I discovered that I can just inject a method that accesses the variables scope and pulls a reference to these components out of the cache, by-passing all normal security check that I have build into my getService() routine.

Andrew Penhorwood

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f743136f-8e30-4808-8b9c-cb8c41ccab38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/4753d43b-458d-4bf8-9018-a2ac316097c3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/22289635-5106-4000-8f67-abbe1d04df19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/7e27a6f2-95f7-43cb-a378-679d0d74ee26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.