i just found out that my Ubuntu Server 6.10 has login shells for almost all users set in the /etc/passwd file!

That’s a very bad idea because this maybe enabled someone to install “Data Cha0s Back Backdoor” on my machine :-(

I checked this with 2 other fresh Ubuntu Server 6.10 installations and both had the login shells for users like daemon, mail, www-data and so on. Especially www-data should not have a chance to create a shell in my opinion!

So i changed /bin/sh to /usr/sbin/nologin and hope this makes it a bit more secure.

since i’m not very experienced with Zope 3 (yet) i had some troubles to turn a text input field in my own content type into a Rich Text Editor using z3c.widget.tiny. This is how i finally got it working (thanks to dobee):

in my interfaces.py file for my content type i defined a normal Text field:

...
description = zope.schema.Text(
title = u"Description",
description = u"describe yourself",
required = False)
...

in my viewclass file (browser.py) i use formlib to handle things, therefore i had to use custom_widget to use the TinyWidget:

import zope.traversing.browser
from zope.formlib import form
from zope.app.pagetemplate import ViewPageTemplateFile
from z3c.widget.tiny.widget import TinyWidget
from training.forms import interfaces, mycontent

class myTinyWidget(TinyWidget):
mce_language = 'de'
mce_theme_advanced_disable = 'bold,italic'
mce_cleanup = 'false'
mce_entity_encoding="raw"

class AddMyContent(form.AddForm):
form_fields = form.FormFields(interfaces.IMyContent)
form_fields['description'].custom_widget = myTinyWidget

def create(self, data):
return mycontent.MyContent(**data)

def add(self, ob):
count = 0
while ‘mycontent-%i’ %count in self.context:
count += 1;
self.context['mycontent-%i' %count] = ob
self._finished_add = True
self._name = ‘mycontent-%i’ %count
return ob

def nextURL(self):
return zope.traversing.browser.absoluteURL(
self.context, self.request) + ‘/’ + self._name

class DisplayMyContent(form.DisplayForm):
form_fields = form.FormFields(interfaces.IMyContent)

template = ViewPageTemplateFile(’view.pt’)

class EditMyContent(form.EditForm):

form_fields = form.FormFields(interfaces.IMyContent)
form_fields['description'].custom_widget = myTinyWidget

actions = form.EditForm.actions.copy()

@form.action(”Apply and View”)
def handle_edit_view_action(self, action, data):
self.actions['form.actions.apply'].success(data)
url = zope.traversing.browser.absoluteURL(
self.context, self.request)
self.request.response.redirect(url)

some notes:

form_fields['fieldxy'].custom_widget defines the widget to use for this field

we use a class derived from form.DisplayForm to handle the display of the fields using their display widgets

and now comes the part that took me days to figure out ;-) :

when coding the page template we would normally use the display widgets of the fields like this:

My name is <span tal:replace="structure view/widgets/name"/>

but for the description field which uses the Tiny MCE widget for editing text, this doesn’t work, because the normal display widget of a Text field will escape HTML entities (& becomes a & and so on) but we need the unescaped HTML code as we add formatting to the text through Tiny MCE. Therefore we need to access the description field directly in the page template and use structure to render the output as well:

<p tal:replace="structure context/description">
description
</p>

now everything works as expected :-)

It’s really nice that so much zope 3 stuff is available already in Plone 2.5 and Five 1.4. I use formlib and plone.app.form with success. I found three issues, but after solving them it works nicely.

1. I had an “AttributeError: debug” error when trying to use formlib. The cause was that Zope 3 has a debug attribute on requests, while Zope 2 doesn’t. When my widget (in the form) rendered itself, which is zope 3 code, it tried to use the debug attribute on the request, but as the request is a Zope 2 request it couldn’t be found. I fixed this by monkey patching ZPublisher.HTTPRequest and setting the debug attribute to zope.publisher.base.DebugFlags(). I’m told this will be fixed, but as I want this to work now I’ll use the patch for now.
2. If using latest trunk of plone.app.form one should inherit from Five’s EditForm. In earlier versions one needed to inherit directly from zope.formlib’s EditForm, otherwise you couldn’t save forms. plone.app.form did some monkey patching. I’m glad Daniel Nouri changed this behaviour. One should now inherit from Five’s base classes, not directly from zope.formlib’s base classes.
3. formlib is supposed to work, but not all widgets are supported. The OrderedMultiSelectWidget is rendering itself and therefore it’s using the Zope 3 page template engine. The Zope 3 page template engine is not supported in Zope 2. When a path expression (which the template for the widget contains) is traversed it tries to adapt to ITraversable. This will not work in Five as this traverses the url, not path expressions. So the solution is to provide another adapter. The result is that the default Zope 3 adapter for traversing path expressions will be used (for input widgets).

<adapter

for=”zope.app.form.browser.interfaces.IInputWidget”
provides=”zope.app.traversing.interfaces.ITraversable”
factory=”zope.app.traversing.adapters.DefaultTraversable”

/>

Not sure if 1 and 3 are still valid for Five 1.5.