[geeklog-devel] GSoC 2010 is on

[Vincent Furia]

Joe,

Implementing the "user groups" into the core is one design possibility, but
certainly not the only choice and perhaps not the best choice. The other
option would be to have "user groups" implemented completely separately in
its own plugin as suggested by Randy. I can think of many pros and cons to
both approaches.

I don't agree with the statement:

> If the groups aren't supported by core you lose all the security Geeklog is
> founded on. There is no question.
>
Why can't we implement "user groups" in a plugin and without compromising
security? I think adding user groups into the existing (core) group model
has at least an equal chance of  introducing security holes as implementing
these groups inside a plugin.

Also, why is it the case:

> But the basic call to COM_getPermSQL must support users' groups or a social
> plugin is a non-starter.
>
With a plugin model, other plugins can be enhanced to check core geeklog
group permissions as well "user groups". If user groups aren't supported,
plugins can gracefully degrade to only supporting COM_getPermSQL.

I'm not advocating one implementation or the other, I haven't given either
enough thought to do so, but I think your stance of there being only way to
implement this with no supporting evidence isn't valid.

-Vinny

On Tue, Feb 16, 2010 at 11:12 AM, Joe Mucchiello <joe at throwingdice.com>wrote:

> At 11:41 AM 2/16/2010, Randy Kolenko wrote:
>
>> a major question of whether this is a core component or is a standalone
>> plugin are still not answered.
>>  <snip>
>>
>> The plugin would expose an api for managing permissions, groups etc etc.
>>
>
> If the groups aren't supported by core you lose all the security Geeklog is
> founded on. There is no question. Core must provide for user owned groups.
> This could be turned off globally to disable all social networking
> capabilities. But the basic call to COM_getPermSQL must support users'
> groups or a social plugin is a non-starter.
>
> I don't understand what the hesitancy is. There is nothing to the design:
>
> A grp_owner NUMBER(8) field must be added to gl_groups. Next, grp_gl_core
> must be made able to hold a 0, 1, or 2. 2 means it is a user group and
> should not show up in the Group Admin screen "normally". From there it's
> just a handful of code cleanup (and a few gotchas I'm sure) to handle
> grp_gl_core issues inside core. If the devteam feels that the bulk of social
> networking should be done in a plugin, this is the minimum core must
> provide. (There might need to be some tweaks to the profile display/edit
> code as well. I'm not sure.)
>
> If a plugin must be done, then the base socnet plugin would have to provide
> all the adding/modifying/removing of private groups code, hopefully in a
> slick AJAXy way. And it would need to create a notification mechanism so
> users can create/accep/deny friend requests. Then other plugins could be
> built on top of that to handle walls, blogs, etc.
>
>
> ----
> Joe Mucchiello
> Throwing Dice Games
> http://www.throwingdice.com
>
>
> No virus found in this outgoing message
> Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.153).
>
> http://www.pctools.com/free-antivirus/
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20100216/b6199ba1/attachment.html>