Re: K3 next steps / brain dump

Hey Dave et al,

IIRC, having HTMLPurifier around would have allowed this.  Did you try
using it with the purifier module active?

I wonder if it wouldn't make sense to re-include HTMLPurifier in
Gallery.  I know it's a biggish library (which is why it was removed
back in the 3.0 beta days), but it's also really well-maintained and
standardized.  And while it may look big, the very first photo any
user uploads to their site is likely to dwarf it.

Thoughts?

Take care,
Shad


On 30 March 2013 02:09, Dave Moore <[email protected]> wrote:
> One issue I had with the existing input sanitation was it was not easy to
> extend or override.  I wanted to be able to add html and script tags in a
> form for a module and in the end I just bypass the input sanitation and used
> the server variable: $_REQUEST
>
> <pre> public function save() {     access::verify_csrf();     // Store form
> values into variables.     $item_id    = Input::instance()->get("item_id");
> // access var directly to get around xss filtering.     $code =
> stripslashes($_REQUEST["code"]);     // update the DB
> ....
> </pre>
>
> There is a couple of modules that do this to bypass the XSS sanitation as it
> was hard to extend.  I know that input sanitation is needed, but for admins
> they should be able to bypass some of this by a module if needed.
>
> Keep up the great work!
>
> Cheers!
> Dave
>
>  On 2013-03-29 5:59 PM, Shad Laws wrote:
>
> Hey gang,
>
> I have one quick Input-related update to the blurb below...
>
> So, I asked where would be the logical place to put the input cleansing, and
> I found part of my answer: in Kohana's core.  Kohana::init() calls
> Kohana::sanitize() on the GPC globals.  However, it doesn't seem like
> sanitize does a whole lot by itself.
>
> In any case, if we wanted to add something a bit more XSS-resilient, perhaps
> extending the Kohana::sanitize() function might be a decent way to do it?
>
> Take care,
> Shad
>
>
> On 29 March 2013 18:22, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>
>> Hey gang,
>>
>> Now that I've wrapped up the big rename/move/search/replace task for all
>> the modules, I'm trying to put together my thoughts and figure out what I
>> should attack next.  I thought maybe putting my brain dump here might be
>> useful, so enjoy :-).  Any and all thoughts/critiques welcome.
>>
>> My overall strategy: put the tasks that are required before gallery can
>> run at all first.  This makes debugging the others much easier.
>>
>> I've loosely "assigned" them to Bharat or myself below, mostly based on
>> what I think each of us has already started.  I'm sure the list is
>> incomplete, but it's a starting point.  Also, I'm not sure I know the status
>> of Bharat's stuff, so his stuff might or might not already be done...
>>
>> Shad's todo before gallery can run:
>> - Module class/file rename/move/search/replace task (done, but probably
>> needs cleanups as we move along)
>> - Theme class/file rename/move/search/replace task (see related email
>> chain)
>> - Make some Gallery-specific module-name-to-class-name translation
>> functions (see below)
>> - K2->K3 replacement: expires (should be easy)
>> - K2->K3 replacement: Input (see below)
>>
>> Bharat's todo before gallery can run:
>> - K2->K3 replacement: ORM and ORM_MPTT
>> - K2->K3 replacement: Database
>> - K2->K3 replacement: Cache
>> - bootstrap.php and index.php (note: I did the class name search'n'replace
>> thing here)
>> - Routing
>>
>> Shad's todo after gallery is (at least barely) running:
>> - K2->K3 replacement: Forge -> Formo (*much* easier to do this after
>> gallery is running)
>> - Make unified Hook API
>> - K2->K3 replacement: Image
>> - Change GalleryGraphics stuff (see related email chain)
>> - Make URL use SERVER_NAME instead of HTTP_HOST
>>
>> Yet-to-be-assigned todo after gallery is (at least barely) running:
>> - K2->K3 replacement: Pagination (see below)
>> - K2->K3 replacement: transliterate and purifier (still referenced in core
>> code)
>> - K2->K3 replacement: unit_test (replaced by php_unit?)
>> - Revise gallery_unit_test and unit test classes
>>
>> ------------
>>
>> Module-name-to-class-name translation functions
>>
>> We need a pair of functions that go back and forth between names_like_this
>> and NamesLikeThis.  This is used both to translate between module names and
>> their classes (parsing urls, finding module hooks) as well as between model
>> names and their table names (ORM).  At first, I thought that K3's built-in
>> Inflector::camelize() and Inflector::decamelize() were a good match, but am
>> no longer entirely sure.
>>
>> Inflector::camelize($str) gives:
>> - gallery --> gallery
>> - server_add --> serverAdd
>> - g2_import --> g2Import
>> - g2_import_event --> g2ImportEvent
>> - html5_example --> html5Example
>>
>> This is fixed with ucfirst(Inflector::camelize($str)), but it's kinda ugly
>> and inefficient (see Kohana_Inflector::camelize()).  So, I extended
>> Inflector to add a $ucfirst argument.  Now, Inflector::camelize($str, true)
>> makes NamesLikeThis.  Default is false to keep it like Kohana intended.
>>
>> Inflector::camelize($str, true) gives:
>> - gallery --> Gallery
>> - server_add --> ServerAdd
>> - g2_import --> G2Import
>> - g2_import_event --> G2ImportEvent
>> - html5_example --> Html5Example
>>
>> Okay, so that mostly works.  Now, the other direction.
>>
>> Inflector::decamelize($str) gives:
>> - FooBar --> foo_bar
>> - G2Import --> g2import
>> - G2ImportEvent --> g2import_event
>> - Html5Example --> html5example
>>
>> The problem is that decamelize looks for [a-z][A-Z], which doesn't work
>> with numbers.  One approach is to just do an extension like I did before
>> (e.g. a new $num_sensitivity argument that changes it to [a-z0-9][A-Z]).
>> That said, this is starting to make we wonder if extending the built-in
>> functions is really a good approach and if we wouldn't be better served with
>> two purpose-built functions instead.  Thoughts?
>>
>> ------------------------
>>
>> Pagination
>>
>> This library was originally in Kohana 2.x, but left after 2.3, so we put
>> it in kohana23_compat for 2.4.  Similarly, it was originally in Kohana 3.x
>> but left after 3.1.  Some folks forked the module and made it compatible
>> with 3.2 (https://github.com/kloopko/kohana-pagination), and others forked
>> that to make it work with 3.3
>> (https://github.com/webking/kohana-pagination).  Does it seem like pulling
>> this in as another module is a reasonable idea?
>>
>> BTW, this is the only thing left in the kohana23_compat module...
>>
>> -----------------------
>>
>> Input
>>
>> This library is gone with K3.  Instead, they recommend working with $_GET,
>> $_POST, and $_SERVER directly.  Handling unset and default values can be
>> handled using Arr as:
>> Arr::get($_POST, "foo", "default foo");
>>
>> This part is pretty straightforward.  The only catch is that they need
>> cleaning first.
>>
>> It was recommended to use Security::xss_clean() with K3.0, but that's
>> since disappeared.  I'm looking for the best alternative, which shouldn't be
>> too hard to find, but think the bigger question is this: *where* do we do
>> this so nobody downstream has to think about it?
>> - bootstrap?
>> - an extension of Route?
>> - an extension of Controller?
>> - somewhere else?
>>
>> ---------------
>>
>> Thoughts?
>>
>> Thanks for listening to my ramblings!
>>
>> Take care,
>> Shad
>
>
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
>
>
>
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]