forked from ScoDoc/DocScoDoc
128 lines
4.8 KiB
Plaintext
128 lines
4.8 KiB
Plaintext
A lot of this stuff is now covered in the Unenlightened Zopistas Guide to
|
|
exUserFolder, so this document is slightly redundant (but not completely).
|
|
It's also shockingly out of date...
|
|
|
|
A note on the version numbering... there's none of that odd/even
|
|
numbering nonsense you find in Lin*x land. The numbers are based on
|
|
|
|
Major.Minor.Micro
|
|
|
|
A bump in Major means a milestone or set of milestones has been reached.
|
|
A bump in Minor means some piece of functionality has been added, or
|
|
a major bug was fixed.
|
|
A bump in Micro usually means bug fixes.
|
|
|
|
These numbers go from 0-99, and are not necessarily continuous or
|
|
monotonically increasing (but they are increasing).
|
|
|
|
What you consider major and what I consider major are probably two
|
|
different things.
|
|
|
|
Release candidates before a Major bump start at 99.. so;
|
|
|
|
0.99.0 is the first Release Candidate prior to 1.0.0
|
|
0.99.1 is the next Release Candidate
|
|
1.0.0 is the 'final' release.
|
|
|
|
It's possible that there will be no changes between final release candidate
|
|
and release.
|
|
|
|
Sometimes due to the nature of the changes a release will be marked
|
|
development. This usually means some core functionality was changed.
|
|
|
|
Extensible User Folder
|
|
|
|
Extensible User Folder is a user folder that requires the authentication
|
|
of users to be removed from the storage of properties for users.
|
|
|
|
Writing new authentication or property sources is (almost) a trivial operation
|
|
and require no authentication knowledge to write, most simply return lists
|
|
of attributes, or dictionaries. You don't need to incorporate them into
|
|
the base exUserFolder code, they can be written as normal Zope Products,
|
|
(i.e. you can distribute new sources independently of exUserFolder).
|
|
|
|
There are three authentication sources provided OOTB;
|
|
|
|
o pgAuthSource -- Postgresql Authentication Source
|
|
Actually this is pretty generic, and could be used for most SQL databases,
|
|
the schema isn't all that advanced either.
|
|
|
|
This source allows you to specify the table, and the name of each of the
|
|
columns (username, password, roles), so you can use an existing database.
|
|
|
|
|
|
All ZSQL Methods are available inside the pgAuthSource folder for editing.
|
|
You need to have a DB Connection already in place for use.
|
|
|
|
o usAuthSource -- User Supplied Authentication
|
|
This is similar to Generic User Folder, or Generic User Sources for
|
|
Login Manager. You provide a set of methods;
|
|
|
|
createUser -- if you want to create users.
|
|
cryptPassword -- if you want to encrypt passwords.
|
|
listUsers -- return a list of userIds.
|
|
listOneUser -- return a dictionary containing the username, password, and
|
|
a list of roles
|
|
getUsers -- return a list of users ala listOneUser but lots of them.
|
|
|
|
that's it. listOneUser is mandatory.
|
|
|
|
There is an example of ExternalMethods you could use to create an 'sql'
|
|
user source in the Extensions directory.
|
|
|
|
o etcAuthSource -- File Based Authentication
|
|
This is etcUserFolder reworked to be a plugin for this. Since I used
|
|
etcUserFolder as a base for this product, I might as well add the functionality
|
|
in.
|
|
|
|
Each of the plugins has a 'manage_addForm' that is called when the User Folder
|
|
is added, so that parameters can be garnered from the user (pg*Source e.g.
|
|
get the dbconnection)
|
|
|
|
etcAuthSource doesn't allow roles to be set, although it does ask for
|
|
a default role to be assigned to a user (which it dutifully does).
|
|
|
|
|
|
There are two property sources provided:
|
|
|
|
o pgPropertySource -- Postgresql Property Source
|
|
A very naive sql implementation for properties, works fine, I wouldn't want
|
|
to load it up too high though.
|
|
|
|
o zodbProperySource -- ZODB Property Source
|
|
This is a very simple property keeper, and is more available as an example
|
|
of what functionality needs to be provided.
|
|
|
|
There is a postUserCreate method which you can replace with anything really,
|
|
if you want to do something once a user is created (send an email to someone,
|
|
page someone...)
|
|
|
|
You can mix-n-match authentication methods and property methods.
|
|
|
|
You can have cookie or standard (Basic) authentication.
|
|
|
|
docLogin and docLogout methods are present in the ZODB for editing, because
|
|
you will hate the way the default login and logout pages look d8)
|
|
|
|
The various plugins need some more configurable options atm, but, it
|
|
shouldn't be that much of a drama to add them in soon.
|
|
|
|
Arbitrary properties can be set on a user (at least if the PropertySource
|
|
is written correctly they can).
|
|
|
|
<dtml-call "AUTHENTICATED_USER.setProperty(key, value)">
|
|
<dtml-if "AUTHENTICATED_USER.hasProperty(key)">
|
|
<dtml-var "AUTHENTICATED_USER.getProperty(key, defaultValue)">
|
|
<dtml-var "AUTHENTICATED_USER['key']">
|
|
|
|
Will all work (assuming the user is logged in).
|
|
|
|
When creating a new user any fields with user_ will be set as properties.
|
|
So 'user_email' field will create an 'email' property. You just have to
|
|
provide the input form, and exUserFolder will do the rest.
|
|
|
|
This has only been lightly tested, but, it seems to work just fine.
|
|
|
|
|
|
|