Re: CakePHP 2.0 meioupload
By the time CakePHP 2.0 went stable, there had been a few other
changes that can cause conflicts with MeioUpload. Here's a Cake2-ready
fork of MeioUpload 2.2:
https://github.com/jdbartlett/MeioUpload
I've also filed a pull request with jrbasso's repo, so check there
first if you've stumbled across this post several months/years in the
future via Google (assuming the zombies haven't devoured us all).
On Oct 26, 10:20 am, zuha wrote:
> Actually I think the preferred way if I'm not mistaken is...
>
> App::uses('File', 'Utility');
> App::uses('Folder', 'Utility');
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
cake-php+unsubscr...@googlegroups.com For more options, visit this group at
http://groups.google.com/group/cake-php
Re: SecurityComponent Logs
I've been thinking about this a little more and agree that this should probably be a separate plugin rather than a patch for the current SecurityComponent. The more I think about it, tokenizing basically serves to prevent record hijacking (overtyping a primary or foreign key or other hidden field in a form) and field insertion (adding extra fields to the form). But most modern web apps expose CRUD methods in a JSON REST API for use with Ajax, where form field hashes don't (or shouldn't) apply. In the threads I've seen on the subject, it's recommended to disable SecurityComponent's POST validation for Ajax requests to avoid black boxes. This exposes the REST API to CSRF attacks. Even when CSRF protection is restored (by checking that Ajax requests include header information, appended to the XHR by JavaScript--non-exotic CSRF attack sites can't do this), record hijacking and field insertion must be coded for manually. Effectively, as far as such applications are concerned, field hashing may as well not exist at all. Perhaps it would be better to produce a plugin that recommends use of fieldLists in save() calls and record ownership verification, instead of relying on field hashing. For CSRF protection, it could use session- specific tokens appended as hidden fields in forms and as HTTP Request Headers in Ajax requests. Does anyone think I've overlooked something with this concept? It's quite an extension of my original goal! Thanks. On Jul 16, 9:00 am, cricket wrote: > On Fri, Jul 16, 2010 at 9:30 AM, jdbartlett wrote: > > SecurityComponent is good for protecting against CSRF attacks, but > > when I encounter a black hole while debugging an app, I want to know > > why. When SecurityComponent black holes a request, it's only capable > > of telling you one thing: you sent a bad request. That's good for > > production--you want attackers to have as little information as > > possible--but it's frustrating for developers who are debugging their > > code. > > > I think it would be helpful if there were an option to have > > SecurityComponent and FormHelper log the unserialized field lists they > > use to produce token hashes. > > > My idea is to create a security.log in tmp/logs with entries like: > > * [Time and Request URI] - Form field hash [hash] based on [field > > list] > > * [Time and Request URI] - Request field hash [hash] based on [field > > list] > > * [Time and Request URI] - Request field hash [hash] does not match > > Form field hash [hash] > > > Because it's intended for debugging specific black holes, I think such > > logging should be a discrete configuration option for > > SecurityComponent. Developers would enable it only when they need to > > work out why a specific request is being black holed. > > > Does anyone else think this would be helpful? Are there good reasons > > to avoid such an approach? I've hacked my own SecurityComponent and > > FormHelper forks to do this, but wanted the community's opinion on the > > idea before cleaning it up and submitting a patch/pull request. > > One vote from me. That seems worthwhile. Perhaps a good approach would > be to create a plugin. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: SecurityComponent Logs
Unless you specify a callback action, SecurityComponent's black holes are always HTTP 404 responses with no body content. Currently, SecurityComponent is designed not to give any information about why it's black holing a response. On Jul 16, 1:24 pm, euromark wrote: > are those black holes 404s? or what error code is thrown? > > On 16 Jul., 16:00, cricket wrote: > > > > > On Fri, Jul 16, 2010 at 9:30 AM, jdbartlett wrote: > > > SecurityComponent is good for protecting against CSRF attacks, but > > > when I encounter a black hole while debugging an app, I want to know > > > why. When SecurityComponent black holes a request, it's only capable > > > of telling you one thing: you sent a bad request. That's good for > > > production--you want attackers to have as little information as > > > possible--but it's frustrating for developers who are debugging their > > > code. > > > > I think it would be helpful if there were an option to have > > > SecurityComponent and FormHelper log the unserialized field lists they > > > use to produce token hashes. > > > > My idea is to create a security.log in tmp/logs with entries like: > > > * [Time and Request URI] - Form field hash [hash] based on [field > > > list] > > > * [Time and Request URI] - Request field hash [hash] based on [field > > > list] > > > * [Time and Request URI] - Request field hash [hash] does not match > > > Form field hash [hash] > > > > Because it's intended for debugging specific black holes, I think such > > > logging should be a discrete configuration option for > > > SecurityComponent. Developers would enable it only when they need to > > > work out why a specific request is being black holed. > > > > Does anyone else think this would be helpful? Are there good reasons > > > to avoid such an approach? I've hacked my own SecurityComponent and > > > FormHelper forks to do this, but wanted the community's opinion on the > > > idea before cleaning it up and submitting a patch/pull request. > > > One vote from me. That seems worthwhile. Perhaps a good approach would > > be to create a plugin. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
SecurityComponent Logs
SecurityComponent is good for protecting against CSRF attacks, but when I encounter a black hole while debugging an app, I want to know why. When SecurityComponent black holes a request, it's only capable of telling you one thing: you sent a bad request. That's good for production--you want attackers to have as little information as possible--but it's frustrating for developers who are debugging their code. I think it would be helpful if there were an option to have SecurityComponent and FormHelper log the unserialized field lists they use to produce token hashes. My idea is to create a security.log in tmp/logs with entries like: * [Time and Request URI] - Form field hash [hash] based on [field list] * [Time and Request URI] - Request field hash [hash] based on [field list] * [Time and Request URI] - Request field hash [hash] does not match Form field hash [hash] Because it's intended for debugging specific black holes, I think such logging should be a discrete configuration option for SecurityComponent. Developers would enable it only when they need to work out why a specific request is being black holed. Does anyone else think this would be helpful? Are there good reasons to avoid such an approach? I've hacked my own SecurityComponent and FormHelper forks to do this, but wanted the community's opinion on the idea before cleaning it up and submitting a patch/pull request. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
