Recent changes to patches

understand encryption of /etc/passwd and /etc/shadow

2007-11-18T00:46:22Z

You have to hard-code the place of the file containing the passwords into the code, but hey, then you can use you linux users&paswords in zope!

This will add a crypto source, so we have to integrate it like this:

diff exUserFolder/CryptoSources/__init__.py
4a5
+ import pass_pwd

The attached file is the new crypto source which understands traditional linux crypt and md5 style password hashes. Save it as exUserFolder/CryptoSources/pass_pwd.py

configuration area in the file:
PASSWORDFILES = ['/opt/zope-instances/foo/exUsers/etcUsers']
DEBUG = 0
DEBUG_LOGFILE = '/tmp/pwdtest.log'

cp /etc/shadow $INSTANCE_HOME/exUsers/etcUsers

(re)install the Product with the changes

add an exUserFolder to a subfolder somewhere which does not already have an acl_users folder
Answer to the dialog:
"Authentication Source": "File Based Authentication Source"
all other Sources: "Null * Source"
"Default Password Hashing Method": "Linux style: crypt or md5"

click NEXT -> Password File: etcUsers , Default Role: etcUser
click NEXT -> click "Add" a few times till finished

tested with:

gentoo Base System version 1.12.6
Zope 2.9.4

MD5 Hex CryptoPlugin for PHP/MySQL/etc compatibility

2005-05-11T10:01:11Z

MySQL, PHP and md5sum (among others) generate hex
representations of MD5 sums which are not compatible
with the existing md5 implementation in pass_md5.py.
This patch adds a new 'MD5 (Hex)' crypto plugin based
on the existing one which allows users to generate new
and authenticate against existing hex md5 hashes,
thereby avoiding having to reissue passwords to
existing users.

This should also allow for migrations from other
products, for example from phpBB to CMFBoard.

diff pass_md5.py pass_md5hex.py
32,33c32,33
< digest = digest.digest()
< secret = string.strip(base64.encodestring(digest))
---
> digest = digest.hexdigest()
> secret = string.strip(digest)
43,44c43,44
< MD5Plugin1=CryptoPluginRegister('MD51', 'MD5', 'MD5
Password Only', cryptPassword)
< exUserFolder.cryptoSources['MD51']=MD5Plugin1
---
> MD5Plugin1=CryptoPluginRegister('MD5X1', 'MD5X', 'MD5
(Hex) Password Only', cryptPassword)
> exUserFolder.cryptoSources['MD5X1']=MD5Plugin1
46,47c46,47
< MD5Plugin2=CryptoPluginRegister('MD52', 'MD5', 'MD5
Username + Password', cryptPassword2)
< exUserFolder.cryptoSources['MD52']=MD5Plugin2
---
> MD5Plugin2=CryptoPluginRegister('MD5X2', 'MD5X', 'MD5
(Hex) Username + Password', cryptPassword2)
> exUserFolder.cryptoSources['MD5X2']=MD5Plugin2

patch for [1164195] typo in zodbPopSource.py

2005-04-06T04:23:18Z

See the bug report at [1164195] typo in zodbPopSource.py.

Patch to allow domain for cookie

2005-03-11T10:10:28Z

This patch intended for cookie based authentication.
It adds "cookie_domain" property for exUserFolder. This
property determines domain for all setCookie /
expireCookie operation in exUserFolder. The main goal
is to make single authentication for many subdomains
in one domain. For example, we have a domains
a.domain.com, b.domain.com, c.domain.com etc served by
single exUserFolder and want user logged in
a.domain.com became logged in other sites. In this case
we can fill cookie_domain property with ".domain.com"

EXUF and portal_memberdata wrapper

2004-03-01T18:45:53Z

XUFUser.getId() tries obtain Id from self.propSource first
which causes infinite reqursion because CMF/Plone
property sources need object Id to fetch object's
properties so they call getId() which tries to get Id
from the self.propSource and so on and so on.
In general it is not a good idea to keep object's Id
separately from the object itself. Confusion seems to
come from the fact that User.id is not a unix user id or
windows user id or database user key or whatever.
User.id is an internal Zope identifier which should be
unique within parent's context and should be always
available. Proposed patch simply removes check in
self.propSource and makes XUFUser.getId() just return
self.name. Probably using username as an id for
XUFUser objects is not an unique or a best solution in
general, but at least it is consistent with other acl_user
implementations.

changing roles with etcAuthSource

2004-01-15T22:07:41Z

I don't know if this is the same bug as with Patch
#626934, but that particular patch entry didn't have
and comments or attached files.

The offending code (from etcAuthSource.py):

232: if roles and self.default_role:

233: roles=roles.append(self.default_role)

234: elif self.default_role:

235: roles=[self.default_role,]

236: else:

237: roles=[]

Line 233 is the problem. 'roles.append' will always
return None, it should just be used in-place.
Currently, if you have any roles manually defined for a
user, then line 233 will just set 'roles' to 'None'.
Zope expects a sequence, not 'None'.

I've attached a small patch.

Simple backwards compatibility patch

2003-08-25T02:52:38Z

I was updating my exUserFolder version and came across
a problem when accessing an older exUserFolder

Fixed by changing line 922 of v0.20.0 from:

if self.currentMembershipSource and
self.currentMembershipSource.loginPage:

to:

if getattr(self, 'currentMembershipSource', None) and
self.currentMembershipSource.loginPage:

Crypting passwords with crypt, md5, sha in pgAuthSourceAlt

2003-02-24T21:17:16Z

This is a patch for pgAuthSourceAlt to allow
configureable crypting method (crypt, md5, sha) for
storing passwords.

It uses the usual method '{SHA}ae34cb...' strings to
store secret.

If you apply this patch, and have an existent
acl_users, you can call the method 'upgrade' on the
'pgAuthSourceAlt' instance, and convert passwords!

viktor at neotek dot hu

fix for use in root folder

2003-02-21T10:45:58Z

Im sure Ive submitted this one previously, but
sourceforge thinks not.

This patch fixes gross brokenness when used as a user
folder in the root folder.

The XUF documentation recommends against doing this on
principal. I disagree with that principal ;-) This
patch works for me.

a typo that prevent changing roles using etcAuthSource

2002-10-22T15:52:27Z