Re: K3 next steps / brain dump
Dave Moore <[email protected]> Fri, 29 Mar 2013 19:09:22 -0600
| Newsgroups | gmane.comp.web.gallery.devel |
|---|---|
| Message-ID | <[email protected]> |
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]
> <mailto: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 ]