Re: Re: UnicodeDecodeError
Philipp von Weitershausen <[email protected]> Fri, 09 Dec 2005 12:18:56 +0100
| Newsgroups | gmane.comp.web.zope.zodb.dirstorage |
|---|---|
| Message-ID | <[email protected]> |
Toby Dickenson wrote:
>>a) FileStorage doesn't seem to have a problem with it
>
> I think it will have the same problem. afaict, FileStorage.format.TxnHeader
> uses str() to convert all these parameters to a plain string, and will
> therefore behaves the same way as DirectoryStorage. It will raise the same
> UnicodeError exception if given a unicode string containing anything other
> than ascii (7bit) values.
Right, which makes we wonder why I can't reproduce this with FileStorage
but with DirectoryStorage (yes, I can actually reproduce it with
DirStorage).
Here's what I did:
- Create a Pluggable Authentication Utility in /++etc++site/default and
activate it. Also activate the default credential plug-ins.
- Create a Principal Folder in the PAU and activate it. Also activate it
in the PAU management screen.
- Create a principal within the Principal Folder and give it an
arbitrary name and password.
- On the root folder, grant the newly created principal the zope.Manager
("Site Manager") role (dunno if that was even necessary).
- Take a new browser (or throw away your current log-in information) and
log into Zope with the newly created principal.
This works with FileStorage (I'm even using this in production on
worldcookery.com), but it fails presenting the error reported originally
by Frank.
I have no explanation why there's a difference in behaviour on
FileStorage and DirStorage if their assumptions on the input seem to be
the same. I'll try to investigate further.
>>Principal IDs (what used to be known
>>as user names in Zope 2) can very well be unicode strings, in fact, they
>>actually *should* be, as specified by the
>>zope.security.interfaces.IPrincipal interface
As a follow-up, I've found that principals defined through ZCML don't
comply with that. Their IDs are strings as they have to comply with the
ID field (ID fields specify that a string must be either a dotted name
like 'zope.Manager' or a URI)
> but ITransaction requires that the 'user' and 'description' attributes are
> type str.
Right. Zope 3 is wrong here. Either the choice of principal IDs being
unicode is correct, in which case it must make sure to only pass an
8byte string to the transaction, or we should revise Zope 3's choice of
using unicode for principal IDs.
I will bring this up among the Zope 3 developers by creating a collector
issue.
Philipp
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click