I'm trying to implement Portcullis as a defence against scripting attacks, etc.
I started by running it on the URL and FORM scopes at the start of the setupRequest() method, but this had no effect - I realised because the request.context has already been populated from the URL and FORM scopes.
My question is this: at the start of the requestSetup method, are the only values in request.context the values populated by the URL and FORM scopes? If I run:
var Portcullis = getBeanFactory().getBean('Portcullis'); Portcullis.scan(request.context, 'request.context', cgi.remote_addr);
...I want to be sure it's not going to have any effect on any other values in request.context.
Or should I use onRequestStart() to run the scans on URL and FORM before they're populated into request.context?
> I'm trying to implement Portcullis as a defence against scripting
> attacks, etc.
> I started by running it on the URL and FORM scopes at the start of the
> setupRequest() method, but this had no effect - I realised because the
> request.context has already been populated from the URL and FORM scopes.
> My question is this: at the start of the requestSetup method, are the
> only values in request.context the values populated by the URL and FORM
> scopes? If I run:
> var Portcullis = getBeanFactory().getBean('Portcullis');
> Portcullis.scan(request.context, 'request.context', cgi.remote_addr);
> ...I want to be sure it's not going to have any effect on any other
> values in request.context.
> Or should I use onRequestStart() to run the scans on URL and FORM before
> they're populated into request.context?
Just curious: why didn't scanning request.context work? In your setupRequest you shouldn't be stepping over any of the RC vars you're populating in your controllers, so that seems like a great time to check everything in one place without needing to the gymnastics you're going through. That would also let you load Portcullis in your beanFactory (or as a local variable in your setupApplication) and use it as a service instead of having separate application variables running around (which would also open up more flexibility to use its other methods in your controllers).
That's what I did originally - but in practice it didn't work.
On pages where a redirect has occurred - passing rc values through to the target page - these values are also in the request.context at the start of setupRequest(). And if these values are not simple values (for instance, passing a struct or an object), then Portcullis throws an error.
I got around this by looping through request.context, creating a new struct with all the simple values in it, running this through Portcullis, then appending the cleaned struct back into request.context - but in the end this seemed like a lot of hoops to jump through, and added unnecessary processing (although probably not too much of a performance hit).
I think Portcullis could use a little development to allow all the scans to be done in one go - and so just return the single isDetected() value, which would remove some of the "gymnastics". When I've got some time, I might work on that...
> Nathan Dintenfass <mailto:nat...@dintenfass.com> > 25 February 2011 19:05
> Just curious: why didn't scanning request.context work? In your > setupRequest you shouldn't be stepping over any of the RC vars you're > populating in your controllers, so that seems like a great time to > check everything in one place without needing to the gymnastics you're > going through. That would also let you load Portcullis in your > beanFactory (or as a local variable in your setupApplication) and use > it as a service instead of having separate application variables > running around (which would also open up more flexibility to use its > other methods in your controllers).
> Seb Duggan <mailto:seb.dug...@gmail.com> > 24 February 2011 10:43
> I'm trying to implement Portcullis as a defence against scripting > attacks, etc.
> I started by running it on the URL and FORM scopes at the start of the > setupRequest() method, but this had no effect - I realised because the > request.context has already been populated from the URL and FORM scopes.
> My question is this: at the start of the requestSetup method, are the > only values in request.context the values populated by the URL and > FORM scopes? If I run:
> var Portcullis = getBeanFactory().getBean('Portcullis'); > Portcullis.scan(request.context, 'request.context', cgi.remote_addr);
> ...I want to be sure it's not going to have any effect on any other > values in request.context.
> Or should I use onRequestStart() to run the scans on URL and FORM > before they're populated into request.context?
When you reference services, you're not referencing the specific file, but an instance of the service object and a method to perform some action - dot notation is appropriate. The sames goes for actions, the dot notation references an instance of a controller and an "item" method that needs to be executed.
When working with views, the framework doing a file lookup starting from your application's "view" folder. The slash is natural for file paths. If we specified dot notation for views, we would have to use a regex and replace all instances of a dot with a slash - which would be a little less efficient than using the slash as we currently do. You don't have to specify the .cfm file extension as it's implied and added by the framework.
-Dutch
On Mon, Feb 28, 2011 at 6:59 PM, Nathan Dintenfass <nat...@dintenfass.com>wrote:
> When you reference services, you're not referencing the specific file, > but an instance of the service object and a method to perform some > action - dot notation is appropriate. The sames goes for actions, the > dot notation references an instance of a controller and an "item" method > that needs to be executed.
> When working with views, the framework doing a file lookup starting from > your application's "view" folder. The slash is natural for file paths. > If we specified dot notation for views, we would have to use a regex and > replace all instances of a dot with a slash - which would be a little > less efficient than using the slash as we currently do. You don't have > to specify the .cfm file extension as it's implied and added by the > framework.
> -Dutch
> On Mon, Feb 28, 2011 at 6:59 PM, Nathan Dintenfass > <nat...@dintenfass.com <mailto:nat...@dintenfass.com>> wrote:
> I'm working on that presentation about FW/1 (which I'll share) -- > brought up a question that has always bugged me:
> Why in view() and setView() do we have to use a "/" instead of a "." > -- seems to make it unparallel with all other places we refer to an > action.
The reason is because you are NOT specifying an action. The "view" method is much more flexible than what we allow for actions since it allows you to organize sub-views with as deep of a directory structure as you want underneath the views directory. The syntax of an action has a very specific meaning ("section.item") and is parsed in a manner that does not allow for the possibility of finding views further down in the directory structure. I think the reasoning for different syntax in the "view" method has more to do with not confusing people into thinking it has the same limitations as actions and not wanting to confuse people into thinking that actions allow additional dots to go deeper into the directory structure.
Why in view() and setView() do we have to use a "/" instead of a "." -- seems to make it unparallel with all other places we refer to an action.
> The reason is because you are NOT specifying an action. The "view" method is much more flexible than what we allow for actions since it allows you to organize sub-views with as deep of a directory structure as you want underneath the views directory. The syntax of an action has a very specific meaning ("section.item") and is parsed in a manner that does not allow for the possibility of finding views further down in the directory structure. I think the reasoning for different syntax in the "view" method has more to do with not confusing people into thinking it has the same limitations as actions and not wanting to confuse people into thinking that actions allow additional dots to go deeper into the directory structure.
> Why in view() and setView() do we have to use a "/" instead of a "." > -- seems to make it unparallel with all other places we refer to an > action. > -- > FW/1 on RIAForge: http://fw1.riaforge.org/
On Tue, Mar 1, 2011 at 7:10 AM, Ryan Cogswell <ryancogsw...@gmail.com> wrote: > The reason is because you are NOT specifying an action. The "view" method > is much more flexible than what we allow for actions since it allows you to > organize sub-views with as deep of a directory structure as you want > underneath the views directory. The syntax of an action has a very specific > meaning ("section.item") and is parsed in a manner that does not allow for > the possibility of finding views further down in the directory structure. I > think the reasoning for different syntax in the "view" method has more to do > with not confusing people into thinking it has the same limitations as > actions and not wanting to confuse people into thinking that actions allow > additional dots to go deeper into the directory structure.
> Why in view() and setView() do we have to use a "/" instead of a "." > -- seems to make it unparallel with all other places we refer to an > action.
> The reason is because you are NOT specifying an action. The "view" method > is much more flexible than what we allow for actions since it allows you to > organize sub-views with as deep of a directory structure as you want > underneath the views directory. The syntax of an action has a very specific > meaning ("section.item") and is parsed in a manner that does not allow for > the possibility of finding views further down in the directory structure. I > think the reasoning for different syntax in the "view" method has more to do > with not confusing people into thinking it has the same limitations as > actions and not wanting to confuse people into thinking that actions allow > additional dots to go deeper into the directory structure.
> Why in view() and setView() do we have to use a "/" instead of a "." > -- seems to make it unparallel with all other places we refer to an > action.
