|
Thanks Scott, Yeah, we used to develop in Fusebox before
mach-ii and honest I feel that things are more secure than ever so when he said
that he felt that mach-ii might be a security risk I was completely stumped.
I’ve never had to justify Mach-ii to anyone so I really just tabled it
and told him that I would just do some research tonight and present him with a
document tomorrow. This listserv has given me enough information to say that
I’ve consulted some people I the cf community and have been assure that
mach-ii poses no risk and if he is still not satisfied to give me a detailed
description of his concerns so I can dispel them. Thanks to everyone that was able to give
their opinion and thanks for the idea about securing the xml file, thinking
about it that’s pretty much the only thing that I can think of that could
pose a problem. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Mach-II
isn't a security risk at all, its no more a security risk then actual hand-code
you write. The only concerining part that I would potentially flag is the
config.xml being exposed to the web (if its got sensitive data inside). This is
easily fixed by either hiding it under the webroot, or naming it config.cfm,
put a application.cfm in the same dir that has <cfabort> The
purpose of Mach-II in the end was to enable your Presenter and View access to
your abstract model (that's my thoughts anyway). Mach-II really only takes
charge of how your presenter/controller works while also allowing you to piece
clumps of UI together. It does this by formulating an event process to the
point where you can intercept events for specific needs or simply keep a nice
consistent re-useable Web-based workflow. The fact
its "implicit invocation security" was even mentioned shows that most
likely BuzzWord bingo is being played here. Ask him what airline article he dug
that upfrom - or if you want to keep your job - simply ask "How do you
mean? What are you're concerns". Scott.
>
-----Original Message----- |
Title: RE: [CFCDev] implicit invocation security concerns
- RE: [CFCDev] implicit invocation security concerns Joe Ferraro
- Re: [CFCDev] implicit invocation security concerns Sean Corfield
- RE: [CFCDev] implicit invocation security conce... Joe Ferraro
- RE: [CFCDev] implicit invocation security c... Jim Davis
- Re: [CFCDev] implicit invocation securi... Bill Rawlinson
- RE: [CFCDev] implicit invocation security c... Ben Rogers
- Re: [CFCDev] implicit invocation securi... Doug Keen
- Re: [CFCDev] implicit invocation securi... Cameron Childress
- RE: [CFCDev] implicit invocation security c... Brian Kotek
- Re: [CFCDev] implicit invocation security c... Sean Corfield
- Re: [CFCDev] implicit invocation security c... Cameron Childress
