[Checkins] SVN: bluebream/website/docs/v1.0/tutorial4.rst bit cleanup
Baiju M
baiju.m.mail at gmail.com
Tue Aug 17 13:08:19 EDT 2010
Log message for revision 115740:
bit cleanup
Changed:
U bluebream/website/docs/v1.0/tutorial4.rst
-=-
Modified: bluebream/website/docs/v1.0/tutorial4.rst
===================================================================
--- bluebream/website/docs/v1.0/tutorial4.rst 2010-08-17 16:25:35 UTC (rev 115739)
+++ bluebream/website/docs/v1.0/tutorial4.rst 2010-08-17 17:08:18 UTC (rev 115740)
@@ -127,41 +127,50 @@
the `View` permission. This makes the description and the items accessible
to all users. Similarly, change permission for the comment.
-Change the permission of line 46 to `Edit`, since only the message board
-administrator should be able to change any of the properties of the
-MessageBoard object.
+First, in the ``src/tc/collector/configure.zcml`` file update the
+declaration like::
-All the container functionality will only require the view permission, so
-change the permission on line 68 to `View`. This is unsecure, since this
-includes read and write methods, but it will suffice for this demonstration.
+ <class class="tc.collector.ticket.Ticket">
+ <implements
+ interface="zope.annotation.interfaces.IAttributeAnnotatable"
+ />
+ <implements
+ interface="zope.container.interfaces.IContentContainer"
+ />
+ <require
+ permission="tc.View"
+ interface="tc.collector.interfaces.ITicket"
+ />
+ <require
+ permission="tc.View"
+ set_schema="tc.collector.interfaces.ITicket"
+ />
+ </class>
-For the Message we need to be able to set the attributes with the `Add`
-permission, so change line 72 to specify this permission.
+ ...
-Now let's go to the browser configuration file
-(``src/tc/main/configure.zcml``) and fix the permissions there.
+ <class class="tc.collector.comment.Comment">
+ <implements
+ interface="zope.annotation.interfaces.IAttributeAnnotatable"
+ />
+ <require
+ permission="tc.View"
+ interface="tc.collector.interfaces.IComment"
+ />
+ <require
+ permission="tc.View"
+ set_schema="tc.collector.interfaces.IComment"
+ />
+ </class>
-The permissions for the message board's add form (line 11), add menu item
-(line 18), and its edit form (line 27) stay unchanged, since only an
-administrator should be able manage the board.
-Since we want every user to see the messages in a messageboard, the
-permission on line 33 should become `View`. Since the contents view is
-meant for management, only principals with the `Edit` permission should be
-able to see it (line 34). Finally, you need the Add permission to actually
-add new messages to the message board (line 35). The same is true for the
-message's container views permissions (line 84-86).
+All the container functionality will only require the view permission, so
+change the permissions to `View`. This is unsecure, since this includes
+read and write methods, but it will suffice for this demonstration.
-Since all user should be able to see the message thread and the message
-details, the permissions on line 43, 94, and 106 should become `View`.
+Now let's go to the browser configuration file
+(``src/tc/main/configure.zcml``) and fix the permissions there.
-On line 61 you should change the permission to `Add`, because you only allow
-messages to be added to the message board, if the user has this
-permission. The same is true for the message's add menu item on line 68.
-
-On line 78 make sure that a user can only access the edit screen if he has
-the `Edit` permission.
-
That's it. If you would restart BlueBream at this point, you could not even
access the TicketCollector and/or Ticket instances. Therefore we need to
create some roles next and assign permissions to them.
@@ -174,12 +183,13 @@
Therefore, the role declaration and grants to the permissions should not
even be part of your package. For simplicity and keeping it all at one
place, we are going to store the policy-specific security configuration in
-security.zcml. For our message board package we really only need two roles,
-*User* and *Admin*, which are declared as follows::
+``src/tc/main/securitypolicy.zcml``. For our ticket collector package we
+really only need two roles, *Member* and *Admin*, which are declared as
+follows::
<role
- id="tc.User"
- title="Ticket collector user"
+ id="tc.Member"
+ title="Ticket collector member"
description="Users that actually use the ticket collector."/>
<role
@@ -187,107 +197,99 @@
title="Ticket collector administrator"
description="The administrator can edit and delete tickets."/>
-Equivalently to the zope:permission directive, the zope:role directive
-creates and registers a new role with the global role registry. Again, the
-id must be a unique identifier that is used throughout the configuration
-process to identify the role. Both, the id and the title are required.
+Equivalently to the ``zope:permission`` directive, the ``zope:role``
+directive creates and registers a new role with the global role registry.
+Again, the id must be a unique identifier that is used throughout the
+configuration process to identify the role. Both, the id and the title are
+required.
Next we grant the new permissions to the new roles, i.e. create a
-permission-role map. The user should be only to add and view messages,
-while the editor is allowed to execute all permission.
+permission-role map. The user should be only to add and view tickets, while
+the editor is allowed to execute all permission.
::
<grant
- permission="book.messageboard.View"
- role="book.messageboard.User"
+ permission="tc.View"
+ role="tc.Member"
/>
<grant
- permission="book.messageboard.Add"
- role="book.messageboard.User"
+ permission="tc.Add"
+ role="tc.Member"
/>
<grant
- permission="book.messageboard.Edit"
- role="book.messageboard.Editor"
+ permission="tc.Edit"
+ role="tc.Admin"
/>
<grant
- permission="book.messageboard.Delete"
- role="book.messageboard.Editor"
+ permission="tc.Delete"
+ role="tc.Admin"
/>
The ``zope:grant`` directive is fairly complex, since it permits all three
different types of security mappings. It allows you to assign a permission
to a principal, a role to a principal, and a permission to a role.
-Therefore the directive has three optional arguments: permission, role, and
-principal. Exactly two of the three arguments have to be specified to make
-it a valid directive. All three security objects are specified by their id.
+Therefore the directive has three optional arguments: *permission*, *role*,
+and *principal*. Exactly two of the three arguments have to be specified to
+make it a valid directive. All three security objects are specified by
+their id.
-Finally, you have to include the security.zcml file into your other
-configuration. This is simply done by adding the following inclusion
-directive in the ZOPE3/principals.zcml file::
-
- <include package="book.messageboard" file="security.zcml" />
-
-The reason we put it here is to make it obvious that this file depends on
-the security policy. Also, when assigning permissions to roles we want all
-possible permissions the system can have to be defined. Since the
-principals.zcml file is the last ZCML to be evaluated, this is the best
-place to put the declarations.
-
Assigning Roles to Principals
-----------------------------
To make our package work again, we now have to connect the roles to some
principals. We are going to create two new principals called boarduser and
boardeditor. To do that, go to the BlueBream root directory and add the
-following lines to principals.zcml:
+following lines to ``src/tc/main/principals.zcml``:
<principal
- id="book.messageboard.boarduser"
- title="Message Board User"
- login="boarduser" password="book"
+ id="tc.jack"
+ title="Ticket collector member"
+ login="jack" password="jack"
/>
<grant
- role="book.messageboard.User"
- principal="book.messageboard.boarduser"
+ role="tc.Member"
+ principal="tc.jack"
/>
<principal
- id="book.messageboard.boardeditor"
- title="Message Board Editor"
- login="boardeditor" password="book"
+ id="tc.jill"
+ title="Ticket collector admin"
+ login="jill" password="jill"
/>
+
<grant
- role="book.messageboard.User"
- principal="book.messageboard.boardeditor"
+ role="tc.Member"
+ principal="tc.jill"
/>
+
<grant
- role="book.messageboard.Editor"
- principal="book.messageboard.boardeditor"
+ role="tc.Admin"
+ principal="tc.jill"
/>
-The zope:principal directive creates and registers a new principal/user in
-the system. Like for all security object directives, the id and title
-attributes are required. We could also specify a description as well. In
-addition to these three attributes, the developer must specify a login and
-password (plain text) for the user, which is used for authentication of
-course.
+The ``zope:principal`` directive creates and registers a new principal/user
+in the system. Like for all security object directives, the *id* and
+*title* attributes are required. We could also specify a description as
+well. In addition to these three attributes, the developer must specify a
+login and password (plain text) for the user, which is used for
+authentication of course.
-Note that you might want to grant the book.messageboard.User role to the
-``zope.anybody`` principal, so that everyone can view and add messages.
+Note that you might want to grant the tc.Member role to the ``zope.anybody``
+principal, so that everyone can view and add tickets.
The ``zope.anybody`` principal is an unauthenticated principal, which is
defined using the ``zope:unauthenticatedPrincipal`` directive, which has the
same three basic attributes the ``zope:principal`` directive had, but does
not accept the login and password attribute.
-Now your system should be secure and usable. If you restart Zope 3 now, you
-will see that only the message board's Editor can freely manipulate objects.
-(Of course you have to log in as one.)
+Now your system should be secure and usable. If you restart BlueBream now,
+you will see that only the ticket collector's Admin can freely manipulate
+objects. (Of course you have to log in as one.)
Conclusion
More information about the checkins
mailing list