× Warning! This forum is in archival status. New contributions may not work.
[campsite-dev] Components from LiveSupport
  • --=_mixed 00540DEBC1256ED3_=
    Content-Type: multipart/alternative; boundary="=_alternative 00540DEBC1256ED3_="

    --=_alternative 00540DEBC1256ED3_=
    Content-Type: text/plain; charset="us-ascii"

    Hi,

    It might also be useful for the Campsite developers to be aware of the
    components that are being developed for the LiveSupport project, which are
    intended as PHP PEAR modules. Micz has written to the campsite-dev list
    previously about the auth module serving as the base for any CMS work we
    do in the future, and I agree with that approach. So, in that spirit, here
    are the relevant modules coming from the Green Box/Live Support projects.

    - Authentication, which handles which users and groups can do.
    - Workflow, which determines what happens to objects when a user works on
    them
    - File archive, which stores metadata describing an object (in this
    instance a sound file, but other objects are supported) as well as a
    pointer to object on the file system. The file archive module replaces the
    MMA multimedia archive, which proved to be too difficult and unwieldy to
    use for this purpose.
    - File transfer, which governs upload and download of objects
    - HTML GUI interfaces to these modules

    We are planning an API which will allow Campsite (the pre-3.0 C++ version,
    I presume) to use the file archive system either instead of or in
    addition to the MySQL database. This part is still fuzzy, and it would be
    good if Tomas Hlava, the developer of these modules, got together with the
    Campsite developers to work on this a bit more.

    I'm including Tomas' RFC for the auth module, which is already written and
    will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be
    forwarded to the Campsite-dev list as we get them done.

    doug





    --=_alternative 00540DEBC1256ED3_=
    Content-Type: text/html; charset="us-ascii"



    Hi,



    It might also be useful for the Campsite developers to be aware of the components that are being developed for the LiveSupport project, which are intended as PHP PEAR modules. Micz has written to the campsite-dev list previously about the auth module serving as the base for any CMS work we do in the future, and I agree with that approach. So, in that spirit, here are the relevant modules coming from the Green Box/Live Support projects.



    - Authentication, which handles which users and groups can do.

    - Workflow, which determines what happens to objects when a user works on them

    - File archive, which stores metadata describing an object (in this instance a sound file, but other objects are supported) as well as a pointer to object on the file system. The file archive module replaces the MMA multimedia archive, which proved to be too difficult and unwieldy to use for this purpose.

    - File transfer, which governs upload and download of objects

    - HTML GUI interfaces to these modules



    We are planning an API which will allow Campsite (the pre-3.0 C++ version, I presume)  to use the file archive system either instead of or in addition to the MySQL database. This part is still fuzzy, and it would be good if Tomas Hlava, the developer of these modules, got together with the Campsite developers to work on this a bit more.



    I'm including Tomas' RFC for the auth module, which is already written and will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be forwarded to the Campsite-dev list as we get them done.



    doug










    --=_alternative 00540DEBC1256ED3_=--

    --=_mixed 00540DEBC1256ED3_=
    Content-type: message/external-body; access-type=URL; URL=http://sympa.mdlf.org/sympa-bin/wwsympa.fcgi/attach/campsite-dev/OFA0B612F8.F3B61C03-ONC1256ED3.0052B57E-C1256ED3.00540DF4@mdlf.org/aarfc_html; name="aarfc_html"; size="9986"

    Content-type: text/html; name="aarfc.html"
    Content-Transfer-Encoding: base64

    --=_mixed 00540DEBC1256ED3_=--

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • 2 Comments sorted by
  • --0__=4EBBE440DFC707A58f9e8a93df938690918c4EBBE440DFC707A5
    Content-type: text/plain; charset=us-ascii


    Please take these into consideration when thinking about CMF versus Pear
    etc.

    Best,

    Sava



    Douglas.Arellane
    s@mdlf.org To: campsite-dev@campware.org
    cc:
    07/16/04 05:18 Subject: [campsite-dev] Components from LiveSupport
    PM
    Please respond
    to campsite-dev







    Hi,

    It might also be useful for the Campsite developers to be aware of the
    components that are being developed for the LiveSupport project, which are
    intended as PHP PEAR modules. Micz has written to the campsite-dev list
    previously about the auth module serving as the base for any CMS work we do
    in the future, and I agree with that approach. So, in that spirit, here are
    the relevant modules coming from the Green Box/Live Support projects.

    - Authentication, which handles which users and groups can do.
    - Workflow, which determines what happens to objects when a user works on
    them
    - File archive, which stores metadata describing an object (in this
    instance a sound file, but other objects are supported) as well as a
    pointer to object on the file system. The file archive module replaces the
    MMA multimedia archive, which proved to be too difficult and unwieldy to
    use for this purpose.
    - File transfer, which governs upload and download of objects
    - HTML GUI interfaces to these modules

    We are planning an API which will allow Campsite (the pre-3.0 C++ version,
    I presume) to use the file archive system either instead of or in addition
    to the MySQL database. This part is still fuzzy, and it would be good if
    Tomas Hlava, the developer of these modules, got together with the Campsite
    developers to work on this a bit more.

    I'm including Tomas' RFC for the auth module, which is already written and
    will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be
    forwarded to the Campsite-dev list as we get them done.

    doug



    (See attached file: aarfc.html)



    --0__=4EBBE440DFC707A58f9e8a93df938690918c4EBBE440DFC707A5
    Content-type: message/external-body; access-type=URL; URL=http://sympa.mdlf.org/sympa-bin/wwsympa.fcgi/attach/campsite-dev/OF60F13D90.0B52D90D-ONC1256ED3.00548135-C1256ED3.0054D550@mdlf.org/aarfc_html; name="aarfc_html"; size="9986"

    Content-type: text/html;
    name="aarfc.html"
    Content-Transfer-Encoding: base64

    --0__=4EBBE440DFC707A58f9e8a93df938690918c4EBBE440DFC707A5--

    ------------------------------------------
    Posted to Phorum via PhorumMail







  • As far as I can tell, and unless I am missing something, the PEAR
    argument is code words for "building it from scratch".  As you can see
    here: http://seagull.phpkitchen.com/?ref=sf#api , any decent CMS will
    be built on top of PEAR.  But nothing in PEAR has anything close to the
    functionality of a full CMS. 









    sava.tatic@mdlf.org wrote:

    cite="midOF60F13D90.0B52D90D-ONC1256ED3.00548135-C1256ED3.0054D550@mdlf.org"
    type="cite">
    Please take these into consideration when thinking about CMF versus Pear
    etc.

    Best,

    Sava



    Douglas.Arellane
    s@mdlf.org To: campsite-dev@campware.org
    cc:
    07/16/04 05:18 Subject: [campsite-dev] Components from LiveSupport
    PM
    Please respond
    to campsite-dev







    Hi,

    It might also be useful for the Campsite developers to be aware of the
    components that are being developed for the LiveSupport project, which are
    intended as PHP PEAR modules. Micz has written to the campsite-dev list
    previously about the auth module serving as the base for any CMS work we do
    in the future, and I agree with that approach. So, in that spirit, here are
    the relevant modules coming from the Green Box/Live Support projects.

    - Authentication, which handles which users and groups can do.
    - Workflow, which determines what happens to objects when a user works on
    them
    - File archive, which stores metadata describing an object (in this
    instance a sound file, but other objects are supported) as well as a
    pointer to object on the file system. The file archive module replaces the
    MMA multimedia archive, which proved to be too difficult and unwieldy to
    use for this purpose.
    - File transfer, which governs upload and download of objects
    - HTML GUI interfaces to these modules

    We are planning an API which will allow Campsite (the pre-3.0 C++ version,
    I presume) to use the file archive system either instead of or in addition
    to the MySQL database. This part is still fuzzy, and it would be good if
    Tomas Hlava, the developer of these modules, got together with the Campsite
    developers to work on this a bit more.

    I'm including Tomas' RFC for the auth module, which is already written and
    will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be
    forwarded to the Campsite-dev list as we get them done.

    doug



    (See attached file: aarfc.html)








    Auth library


    Auth library - request for comments


    Version: 0.1 - the first draft - 28.2.2004, 2.3.2004

    Authentication & authorization


    Authentication - as user's identity
    checking - would be done using PHP session management after user's
    successful login with username/password or XML/HTTP login have been
    done by external application.


    Authorization - as checking user's
    privilege for called action on some object - that's solved problem.


    Basic model


    Subject --- Action ---> Object


    Where:



    • Subject

      is subset from table of users - one user or user group

      [or - optional - general select from user table (with general
      condition)]

    • Action

      is one or more records from predefined action table (selection depends
      on object type)

    • Object

      is a item from object table - specified by class and identification
      within the class



    Subject implementation


    Subjects would be simply implemented by table of users, table of
    groups and many2many relation between users and groups (auxiliary
    table => user may be member of several groups).

    Data may be loaded from existing application.


    Object implementation


    For simple use with existing projects, there would be a object
    tree
    always separated from project's database tables. It would be
    implemented by
    table of objects and information about parent/child (or other) relation
    between
    objects.



    Each object type would be also represented by "object class", which
    have to be registered by application - e.g. provide set of allowable
    actions.


    Example:



    RootNode
    |
    |-> PublicationA
    | \-> Issue1
    | |-> Section(type=sport) <--\
    | \-> Section(type=politics) |
    |-> PublicationB |
    | |-> Issue1 |
    | | |-> Section(type=politics) |
    | | |-> Section(type=sport) <--|
    | | \-> Section(type=culture) |
    | \-> Issue2 |
    | |-> Section(type=culture) |
    | \-> Section(type=politics) |
    | ^ |
    |-> IssueGroup------/ (no condition - all Issues) |
    | |
    \-> SectionGroup(type="sport")---------------------------/

    Object table definition:

    [id, description,
    class, id_within_class]


    and tree description table:

    [obj1_id, type_of_relation, obj2_id class="b">]



    Types of relation: is_child_of, is_member_of etc...

    Class used in example: Publication, Issue, Section, IssueGroup,
    SectionGroup



    Privileges for actions


    There are several ways to handle privileges - I consider this two:

    only allow - more simple method - all without
    allow privilege is denied.

    or allow/deny - less simple - all without allow
    privilege is denied, but more specified setting may overcome less
    specified

    (e.g. group of users is allowed, but one specified group-member is
    denied)


    Privileges would be stored as triple class="b">[subject, action, object]
    and allow/deny flag (if is used).

    rem.: Type of subject (user or group) should be included somewhere.



    Procedure of privilege checking:



    • If exists deny privilege on corresponding object
      for user => DENY

    • If exists allow privilege on corresponding object
      for some user's group => ALLOW

    • If exists allow privilege on corresponding object
      for user => ALLOW

    • otherwise DENY



    Simple objects (e.g.Section) may belong to more complex objects
    (e.g.SectionGroup) - system should first look for privileges associated
    with simple object and then - if nothing found - search privileges on
    complex objects and go up in the tree for inherited privileges.


    Some cache system for authorization decisions would be good ...


    Example:


    Privileges:
     [$admin_id,   allPriv,   $RootNode_id,   allow
     class="b">]
    [$GroupA_id,   writePriv,   $SectionGroupSport_id,   allow class="b">]
    [$userB_id,   writePriv,   $PublA_Issue1_SectionSport_id,   deny class="b">]
    [$userC_id,   addChildPriv,   $PublicationA_id,   allow class="b">]

    Objects:
     [$RootNode_id,   'RootNode',   'RootNode',   ''
     class="b">]
    [$PublA_Issue1_SectionSport_id,   'PublA/Issue1/SectionSport',   'Section',   'id=$id_in_sections_table' class="b">]
    [$SectionGroupSport_id,   'SectionGroupSport',   'SectionGroup',   'type="sport"' class="b">]
    [$PublicationA_id,   'PublicationA',   'Publication',   'id=$id_in_publications_table' class="b">]


    Auth system usage



    There are 3 main types of usage:



    1. authorization of called action

    2. automatic modification of user interface in dependence on user
      privileges

    3. automatic generation of admin interface for privileges settings



    Important part of API


    (Real code should be OO - set of classes with methods.)




    • int initObjectTree()


    • int addObjectTreeNode(parentNode, description, class,
      identification)


      method for object-tree building

    • int registerClass(className, properties)

      I think, it will be needed

    • int login(userName, password)


    • int logout(userName, password)


    • int getPrivilege(user, action, object)

      would be used for every called actions. (usage type 1.)

    • int setPrivilege(user, action, object)

      would be called from admin interface

    • xml getTopLevelEditableObjects(subject)

      in example above provides list of high level items, where user have
      some editation privileges

      (usage type 2.)

    • xml getAdminUI(startNodeId=<RootNodeId>, subject)

      for default RootNode provides list of publications with editation
      elements,

      for startNode pointing to 'PublicationB/Issue2' provides list of
      Sections etc...

      (usage type 3.)

    • addUser(), addGroup(), addUser2Group() ...




    Connection to existing applications


    PHP applications may include this library and call API functions
    directly.

    Other programming platforms may call XML/HTTP layer above API
    functions.


    Applications should be responsible for object tree generation and
    modification by calling API.

    (e.g. when application provides "Add new issue")





    P.S.: sorry for my English ...






    ------------------------------------------
    Posted to Phorum via PhorumMail