Thanks Matt. Another question. What's a good way to secure CFC's?
I have some that work remotely via http, and they require a userID argument. I'm not sure how to secure the CFC's from being abused though. If anybody knows the url, they can put any userID in the string. For instance, I created a simple cfc for creating image folders http://details.at/config/cfc/imageFolderCreate.cfc?method=imageFolderCreate&folderName=myNewTestFolder&userID=9&__BDRETURNFORMAT=wddx But this is all stateless, so I can't (to my understanding) use session data to compare it to. aka userID='#session.myID#' I'm assuming I basically need to create some kind of API key that would be passed along with the rest of the arguments, and the CFC would only run if the API key matches the userID? On Sun, Jul 22, 2012 at 12:12 PM, Matthew Woodward <[email protected]> wrote: > On Wed, Jul 18, 2012 at 11:34 AM, Jason Allen <[email protected]> > wrote: >> >> I'm trying to decide the best way to approach returning the errors to the >> requestee. > > > I use bean-type CFCs to model stuff like this, and I have a validate() > method in the beans. This validate method knows what's valid and what isn't > at that level and if there are errors, I have the validate method populate > an error struct so I know what fields are in error. That way when I pass the > bean CFC back to the form I have all the data they submitted, and with the > error struct I have the fields that are in error so I can display visually > what the problems are and output a list of problems. The error struct uses > the field name as the key and a message (e.g. "The email address you > provided is not valid") as the value. > > For things outside the context of the bean you can check those things in > your controller or preferably your service layer and have that be part of > the overall error struct. > >> My other option is to just use a single 'error' variable and if any >> possible errors surface, they all just set 'error = 1'. That way I only have >> to include a single 'error' bit in the return versus about 20 specific error >> bits. > > > But it's easy enough to keep track of what goes wrong so you can give better > information to the user (which is what you allude to in your next > paragraph). > >> >> The downside is that there'd be no way to tell the requesting app WHICH >> argument caused the error. > > > This is vital. If you don't do this that's an absolutely horrible user > experience. Just saying "something went wrong, try again!" will have your > users running far and fast away from your app. > > -- > Matthew Woodward > [email protected] > http://blog.mattwoodward.com > identi.ca / Twitter: @mpwoodward > > Please do not send me proprietary file formats such as Word, PowerPoint, > etc. as attachments. > http://www.gnu.org/philosophy/no-word-attachments.html > > -- > online documentation: http://openbd.org/manual/ > http://groups.google.com/group/openbd?hl=en -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en
