[geeklog-devel] [contact-us] Updated proposal for GSOC

[Abhishek Shrivastava]

> JSON seems to more commonly used. PHP
> has native functions for JSON as of PHP 5.2 and for earlier versions,
> there's a PEAR package. So that shouldn't be a problem.

Yes, I think JSON will do. Previously, I was doubtful if JSON was the
best choice for parsing at the client-side? Not just JSON has security
issues but in XML, using the Xpath language along with XLST can
retrieve results based on "relations" faster... But I think such type
of "relations"-based retrieval will not be necessary for implementing
an AJAX search-box ...

> I would assume there are best practices so that JSON
> requests aren't easily spoofed.

json.org have released a so-called "JSON parser" in the public domain.
It also uses eval() at its core, but it applies filters beforehand to
reject all the javascript codes in the input and only accept JSON
syntax. http://www.json.org/json2.js
I think we can use this code to boost our json security. However,
before deploying it, I would like to go through the code and write
test-cases to ensure it doesn't have any bugs because the author takes
no guarantee! :|

> In practise, permissions per fieldset are probably fine-grained enough.
> I can imagine that some of the fieldsets need to broken up and
> rearranged, though.

I think we should preserve the current structure of the fieldsets.
Breaking up the current fieldset structure will also disturb the way
the configurations default page looks now. But we are not giving away
with our current configurations page, we are only adding new features
to it. For those users who are accustomed to current arrangement of
fieldsets, it can become a problem. Also breaking down means adding
more number of fieldsets to the configurations pages. This is likely
going to cause more troubles for those who like digging their way into
config pages.

My suggestion is : how about we distinguish between "fieldsets" and
"config-groups" ?? Fieldsets can be kept only for the sake of
displaying a set of similar configurations within a border... Without
having to create more fieldsets, we can actually add a new "column" in
the the conf_values table called "config-group", indicating the ID of
the config-group to which the configuration belongs to... The
advantage of adding a new column is that we can assign a configuration
to multiple config-groups by using comma separated IDs in the
config-group field. If we use fieldset, we would end up displaying one
option twice in the same page under 2 different fieldsets... But in
case of config-groups, we can first take the union of all the
config-groups the user has access to and display them..  and we can
also make use of the fieldset column to group the list of resulting
configurations while displaying on the page...


> From a technical point of view, since the fieldsets and the actual
> options are all in the same table, you would end up with unused
> permission fields on every option, so you may as well go all the way.

This would happen only if we put the permission field in the same
table containing fieldsets and options i.e. the "conf_values" table.
Thats why I am suggesting the creation of a new table, which would
only contain config-groups as entries and the permission fields.

> Is this something that could be implemented in two steps? Per fieldset in
> any case, per option if time permits?

Yes actually it can be implemented. There's no harm in implementing
per-option basis also. After all, it would be under root's control to
use it or not. I think it would be used only at the rarest of rare
situations, but it still adds as a feature to geeklog. If time
permits, it can be done.

> Is there any real benefit in having a second table?

Having a separate table for config_groups will add to the
well-structured core of geeklog, because config_groups are not exactly
"features". Not only it will clutter up the features table with lots
of config entries, but it will also limit the capability to extend the
limits of configuration in future. If we want to add some more
features to the config-groups in future, it would be good if we have a
separate table to apply the new features directly instead of thinking
of ways to accomodate it within the limited structure of the features
table.


I would soon add images in my proposal to better clarify my idea about
access control structure.


With Best Regards,
Abhishek Shrivastava.