Re: K3 next steps / brain dump

Hey Dave et al,

I took a closer look at the purifier module, and I think I see why it
didn't help.  While the Input library was written to optionally use
HTMLPurifier, it looks like we would've had to enable a config
parameter or two to get it to connect.  Near as I can tell, the
purifier module didn't do this...

Take care,
Shad


On 31 March 2013 00:21, Dave Moore <[email protected]> wrote:
> Shad,
> If i remember right (almost a year now) i did try the HTMLPurifier module
> but it did not work for input sensitization.  I think I even used the module
> order module to no avail.   It does work for other inputs but did not
> investigate further as using stripslashes($_REQUEST["code"]); was far easier
> :-)
> Some old discussion slightly related:
> https://sourceforge.net/mailarchive/message.php?msg_id=29134072
> I guess my point/request would be that a module can loosen up the input
> verification.
>
> As for including the heavy HTMLPurifier module; It does add a lot to the
> size and users that want that functionality can add a module like they have
> been doing for some time now, but adding more functionality out of the box
> is better as well.  If the team is concered about size then do what we do
> now (user install module) is the way to go, but like you say one DSLR image
> is the same size.
>
> Dave
>
> On 2013-03-30 9:42 AM, Shad Laws wrote:
>>
>> 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 ]