Portcullis and the setupRequest() method

[Seb Duggan]

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?

Seb

[Seb Duggan]

OK, I've worked it out, and wrote a blog post about it:

http://sebduggan.com/posts/integrating-portcullis-into-fw1-applications

Hope this is useful to anyone else planning on using Portcullis...


Seb

[Nathan Dintenfass]

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]

Hi Nathan,

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 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 25 February 2011 14:03

OK, I've worked it out, and wrote a blog post about it:

http://sebduggan.com/posts/integrating-portcullis-into-fw1-applications

Hope this is useful to anyone else planning on using Portcullis...


Seb

---

Seb Duggan 24 February 2011 10:43

[Nathan Dintenfass]

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.

Thanks ;)

- Nathan D

[Dutch Rapley]

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

--
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

[Nathan Dintenfass]

Sounds like an implementation concern bubbling up to an interface ;)

Thanks for the explanation.

- Nathan

[Ryan Cogswell]

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.

[Nathan Dintenfass]

Ok, sold!  ;)

Thanks,

 - Nathan

--

[Sean Corfield]

What Ryan said :)

> --
> 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
>

--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Dutch Rapley]

That's what I was trying to say, but you said it better!

-Dtuch

--