forked from ScoDoc/ScoDoc
672 lines
24 KiB
Plaintext
672 lines
24 KiB
Plaintext
The Unenlightened Zopistas Guide to exUserFolder.
|
|
(C) 2001-2003 Andrew Milton <akm@theinternet.com.au>
|
|
|
|
0. INTRODUCTION.
|
|
|
|
exUserFolder is an extensible authentication product for the Zope
|
|
Application Server. It allows a user to choose from a number of
|
|
methods of authenticating their users, and allows the setting and
|
|
fetching of arbitrary properties on a User object.
|
|
|
|
Authentication methods, and Property methods do not have to use the
|
|
same backing store, so it is possible to use legacy user sources, and
|
|
still have configuration information stored about a user.
|
|
|
|
exUserFolder supports HTTP Basic Authentication, and the so called
|
|
Cookie Authentication schemes popular with most webservers.
|
|
|
|
0.1 Audience.
|
|
|
|
Everybody, and Nobody. If we build our product correctly, we shouldn't
|
|
need user documentation, that's why Nobody. For some reason, normal
|
|
sane people seem to lose all of their common sense when sitting in
|
|
front of a computer. To the point where plain messages e.g. "Please
|
|
Insert a Floppy", evoke a response of "What does that mean?" So that's
|
|
why this document is for Everybody.
|
|
|
|
This is not a guide for writing your own authentication, property, or
|
|
membership sources. You need the Zen Masters Guide to exUserFolder
|
|
document for that.
|
|
|
|
|
|
1. GETTING STARTED
|
|
|
|
exUserFolder requires Python 2.1 or above (may work with older
|
|
pythons, but, this is not supported). And has been tested on Zope
|
|
2.3.0 and above (including 2.4.3).
|
|
|
|
exUserFolder comes as a source tarball, and it does not rely on any
|
|
outside dependencies to be work. Some items may require additional
|
|
products to be installed in your Zope tree, but, simply will not
|
|
appear if these are not available. Some items may also require
|
|
external products to add functionality to them, but, at no time should
|
|
the Product not install because of these dependencies.
|
|
|
|
|
|
1.1 Installing exUserFolder.
|
|
|
|
Unpack exUserFolder in your Products directory. This can be achieved by
|
|
executing the following on most UNIX systems.
|
|
|
|
gzip -d -c exUserFolder-Ma_Mi_u.tgz | tar xvf -
|
|
|
|
where exUserFolder-Ma_Mi_u.tgz is the version of exUserFolder you have
|
|
downloaded.
|
|
|
|
On systems that have the GNU tar this can be shortened to;
|
|
|
|
tar zxvf exUserFolder-Ma_Mi_u.tgz
|
|
|
|
You should restart Zope after unpacking. Installing the product will not
|
|
affect your Zope installation in anyway.
|
|
|
|
If you go to Folder inside your Zope Management Interface, you should see
|
|
exUserFolder as a dropdown item near the bottom somewhere.
|
|
|
|
Congratulations, it's installed.
|
|
|
|
|
|
2. AUTHENTICATION SOURCES AND YOU.
|
|
|
|
The only mandatory component of an exUserFolder installation, is
|
|
choosing an Authentication Source. There are six Authentication
|
|
Sources to choose from in the default install. There are other add-on
|
|
Sources available from other parties.
|
|
|
|
Each Authentication Source is different, and assumes at least some
|
|
knowledge of that type of authentication scheme.
|
|
|
|
Most if not all sources store the password encrypted in some
|
|
manner. This means that discovering other people's passwords is going
|
|
to be more difficult, than with the standard user folder that comes
|
|
with Zope.
|
|
|
|
By default crypt or fcrypt are used, which is are DES encryption
|
|
methods. While this is not the strongest, fastest, choose another
|
|
superlative, of encryption techniques, it is certainly adequate for
|
|
protecting webpages.
|
|
|
|
In a later release exUserFolder will allow you to choose what method
|
|
is used for password hashing.
|
|
|
|
Some Authentication Sources can list the users that are available,
|
|
some cannot (or will not). Some allow you to add users, and others do
|
|
not. What features are availble depend on the individual
|
|
Authentication Source.
|
|
|
|
|
|
2.1 ZODB Authentication Source
|
|
|
|
The ZODB Authentication Source operates just like a normal User
|
|
Folder. It stores its authentication items in the ZODB as the name
|
|
suggests. This is the simplest folder to setup, requiring no
|
|
parameters.
|
|
|
|
Choosing ZODB Authentication Source is recommended for testing your install.
|
|
|
|
|
|
2.2 File Based Authentication.
|
|
|
|
File Based Authentication allows you to have a fixed set of users in a
|
|
file with their encrypted passwords. The prerequisites for this are
|
|
somewhat convoluted.
|
|
|
|
In the root of your Zope Installation, on the actual file system (not
|
|
in the ZODB), create a directory called exUsers. Make sure that Zope
|
|
has access to that directory.
|
|
|
|
This is the directory where you will create your files.
|
|
|
|
This is a read only Authentication Source. You will not be able to
|
|
create users, or modify their passwords. You can change their roles if you
|
|
choose a Property Source.
|
|
|
|
There are two parameters asked for;
|
|
|
|
2.2.1 Password File
|
|
|
|
This is the name of the file that contains your users and passwords.
|
|
It should be of the format;
|
|
|
|
username:cryptedPassword
|
|
user2:otherCryptedPasswd
|
|
|
|
I can contain other fields after the password also delimited by : but these
|
|
will not be ussed.
|
|
|
|
This file should exist inside the exUsers directory.
|
|
|
|
2.2.2 Default Role
|
|
|
|
This is the role that all users should be given when the log in. Because this
|
|
is a Read Only authentication source, you may not be able to add Roles at a
|
|
later date.
|
|
|
|
|
|
2.3 Postgresql Authentication Source
|
|
|
|
Postgresql Authentication source is an RDBMS backed user store. You
|
|
can add, change, and list users. It requires a Postgresql Database
|
|
Connection to be created before creating the User Folder.
|
|
|
|
You should be familiar with databases, and with your schema before
|
|
using this Authentication Source. If you don't already have a table
|
|
structure in place, a default schema is provided called 'pgScheme.sql'
|
|
in the exUserFolder distribution.
|
|
|
|
The required schema is very simple. You need to store usernames,
|
|
passwords, and roles. If your existing schema doesn't support a roles
|
|
column you will have to add one.
|
|
|
|
The configuration scheme looks daunting, but, it is setup to use the
|
|
defaults for 'pgScheme.sql' so if you're using this you can safely
|
|
continue.
|
|
|
|
We will run through the items.
|
|
|
|
2.3.1 Database Connection
|
|
|
|
If you have any database connections, they will be listed in the drop
|
|
down box. Choose the one that represents your connection to your users
|
|
table.
|
|
|
|
2.3.2 Table Name
|
|
|
|
This is the name of the table containing your users. If you have a
|
|
different table to the default, you should change it here.
|
|
|
|
2.3.3 Username Column
|
|
|
|
This is the name of the column inside your table that contains the
|
|
usernames or logins of your users. This should contain exactly what
|
|
the user needs to type in as their username.
|
|
|
|
|
|
2.3.4 Password Column
|
|
|
|
This is the name of the column inside your table that contains the
|
|
encrypted passwords of your users.
|
|
|
|
|
|
2.3.5 Roles Column
|
|
|
|
This is where the roles are stored. These are used to provide access
|
|
to items in Zope.
|
|
|
|
|
|
2.4 User Supplied Authentication Source
|
|
|
|
This allows you to create your methods in DTML, PythonScripts,
|
|
External Methods, or any other callable Zope item for listing,
|
|
authenticating, adding and changing your users.
|
|
|
|
It is beyond the scope of this guide to describe how to do this, but,
|
|
the API is quite well defined inside the source, and also in the
|
|
README.API document.
|
|
|
|
This Authentication Source has no configuration parameters.
|
|
|
|
|
|
2.5 RADIUS Authentication Source
|
|
|
|
This allows you to authenticate your users against a RADIUS server. If
|
|
you don't know what this means, then this User Source is not for you
|
|
:-)
|
|
|
|
You will require a RADIUS server to be operating, and for the server
|
|
that Zope is running on to have access to it. You will also need to
|
|
know the secret key to access the RADIUS server.
|
|
|
|
2.5.1 Host
|
|
|
|
This is the host your RADIUS server is running on.
|
|
|
|
2.5.2 Port
|
|
|
|
This is the port your RADIUS server is running on. Older installs may
|
|
require this to be 1645. The new 'blessed' port by IANA is 1812, and
|
|
this is now the default port.
|
|
|
|
2.5.3 Secret
|
|
|
|
Every remote host has a secret key it has to share with the server in
|
|
order to gain access to the authentication server. You need to know
|
|
this.
|
|
|
|
2.5.4 Retries
|
|
|
|
Because this is a networked authentication service, errors can
|
|
occur. This sets the number of times it will try to authenticate
|
|
before giving up.
|
|
|
|
2.5.5 Timeout
|
|
|
|
This is how long the RADIUS authenticator will wait for a
|
|
response. Because RADIUS operates over UDP, which is a connectionless
|
|
protocol, answers may never come back, or never reach their
|
|
destination in the first place.
|
|
|
|
The default is 5 seconds which is actually quite a long time.
|
|
|
|
|
|
2.6 SMB Authentication Source
|
|
|
|
This source allows you to authenticate your users in a Microsoft
|
|
Environment, using the SMB protocols. This is not the same as
|
|
authenticating via Directory Services.
|
|
|
|
If your SMB server requires passwords to be encrypted in transit, you'll
|
|
need to install mxCrypto.
|
|
|
|
2.6.1 Host
|
|
|
|
This is the host that your Authentication service is on, this is
|
|
normally an NT or Win2K server, but, it can also be a UNIX box running
|
|
Samba. This should be the NetBIOS name of the server.
|
|
|
|
2.6.2 Domain
|
|
|
|
This is the NT/Windows DOMAIN that the user is to authenticate
|
|
against.
|
|
|
|
2.6.3 WINS Server IP Address (optional)
|
|
|
|
If provided, this should be the IP address of the WINS server to be
|
|
queried to locate your auth host (see 2.5.1 above).
|
|
|
|
If you leave this field empty, the location of the authentication host
|
|
will be queried by broadcast, which works just fine if the Zope
|
|
machine is on the same subnet as your auth host but not if the auth
|
|
host is across a subnet link or if it's in the same machine as Zope
|
|
(don't ask. Apparently, some braindmamaged creature at M$ decided that
|
|
a machine shouldn't answer to its own broadcasts no matter what)
|
|
|
|
Fill in this field if you are getting "NetBIOSTimeout" errors but you
|
|
are sure that your auth host was specified correctly, or if Windows
|
|
machines in your subnet also use a WINS server.
|
|
|
|
|
|
2.7 LDAP Authentication
|
|
|
|
This source allows you to authenticate your users against an LDAP
|
|
server. This code is based on the auth_ldap module for Apache. The
|
|
documentation for these parameters is unashamedly lifted directly from
|
|
the documentation of the Apache directives for auth_ldap.
|
|
|
|
See: http://www.rudedog.org/auth_ldap/
|
|
|
|
You must choose a property source when using LDAP Authentication, all
|
|
of the properties associated with the LDAP user entry are stored as
|
|
properties when they authenticate. Items with multiple entries are
|
|
stored as a list of items.
|
|
|
|
You will need the pyLDAP module installed to use this authsource.
|
|
If you don't have it installed, you will not see an LDAP Auth Source available
|
|
for use.
|
|
|
|
2.7.1 URL
|
|
|
|
An RFC 2255 URL which specifies the LDAP search parameters to use. The syntax
|
|
of the URL is
|
|
ldap://host:port/basedn?attribute?scope?filter
|
|
|
|
ldap For regular ldap, use the string ldap. For secure LDAP, use ldaps
|
|
instead. Secure LDAP is only available if auth_ldap was compiled with
|
|
SSL support.
|
|
host:port The name/port of the ldap server (defaults to localhost:389 for ldap,
|
|
and localhost:636 for ldaps).
|
|
|
|
Once a connection has been made to a server, that connection remains
|
|
active for the life of the Zope process, or until the LDAP server
|
|
goes down.
|
|
|
|
If the LDAP server goes down and breaks an existing connection,
|
|
the Auth Source will attempt to re-connect
|
|
|
|
basedn The DN of the branch of the directory where all searches should start
|
|
from. At the very least, this must be the top of your directory tree,
|
|
but could also specify a subtree in the directory.
|
|
|
|
attribute The attribute to search for. Although RFC 2255 allows a
|
|
comma-separated list of attributes, only the first attribute will be
|
|
used, no matter how many are provided. If no attributes are provided,
|
|
the default is to use uid. It's a good idea to choose an attribute
|
|
that will be unique across all entries in the subtree you will be
|
|
using.
|
|
|
|
scope The scope of the search. Can be either one or sub. Note that a scope
|
|
of base is also supported by RFC 2255, but is not supported by this
|
|
module. If the scope is not provided, or if base scope is specified,
|
|
the default is to use a scope of sub.
|
|
|
|
filter A valid LDAP search filter. If not provided, defaults to (objectClass
|
|
=*), which will search for all objects in the tree.
|
|
|
|
When doing searches, the attribute, filter and username passed by the HTTP
|
|
client are combined to create a search filter that looks like (&(filter)
|
|
(attribute=username)).
|
|
|
|
For example, consider an URL of ldap://ldap.xuf.com/o=XUF?cn?sub?(posixid
|
|
=*). When a client attempts to connect using a username of The Jester, the
|
|
resulting search filter will be (&(posixid=*)(cn=The Jester)).
|
|
|
|
|
|
2.7.2 Bind DN
|
|
|
|
An optional Distinguished Name user to bind to the server when searching
|
|
for entries. If not provided an Anonymous bind will be used.
|
|
|
|
2.7.3 Bind Password.
|
|
A bind password to use in conjunction with the bind DN. Note that the bind
|
|
password is probably sensitive data, and should be properly protected. You
|
|
should only use the Bind DN and Bind Password if you absolutely
|
|
need them to search the directory.
|
|
|
|
2.7.4 Cert DB Path
|
|
|
|
Specifies in which directory LDAP Auth Source should look for the certificate
|
|
authorities database. There should be a file named cert7.db in that directory.
|
|
|
|
2.7.5 Compare DN On Server
|
|
|
|
When set, LDAP Auth Source will use the LDAP server to compare the
|
|
DNs. This is the only foolproof way to compare DNs. LDAP Auth Source
|
|
will search the directory for the DN specified with the require dn
|
|
directive, then, retrieve the DN and compare it with the DN retrieved
|
|
from the user entry. If this directive is not set, LDAP Auth Source
|
|
simply does a string comparison. It is possible to get false negatives
|
|
with this approach, but it is much faster. Note the LDAP Auth Source cache
|
|
can speed up DN comparison in most situations.
|
|
|
|
2.7.6 Dereference Aliases
|
|
|
|
This directive specifies when LDAP Auth Source will de-reference
|
|
aliases during LDAP operations. The default is always.
|
|
|
|
2.7.7 Group Attribute is DN
|
|
|
|
When set, this directive says to use the distinguished name of the
|
|
client username when checking for group membership. Otherwise, the
|
|
username will be used. For example, assume that the client sent the
|
|
username tjester, which corresponds to the LDAP DN cn=The Jester,
|
|
o=XUF. If this directive is set, LDAP Auth Source will check if the
|
|
group has cn=The Jester, o=XUF as a member. If this directive is not
|
|
set, then LDAP Auth Source will check if the group has tjester as a
|
|
member.
|
|
|
|
2.7.8 Compare Cache Size
|
|
|
|
This specifies the size of the cache used to cache LDAP compare
|
|
operations. The default is 1024 entries. Setting it to 0 disables
|
|
operation caching.
|
|
|
|
2.7.9 Compare Cache TTL
|
|
|
|
Specifies the time (in seconds) that entries in the operation cache
|
|
remain valid. The default is 600 seconds.
|
|
|
|
2.7.10 Start TLS
|
|
|
|
If this is set to Yes, LDAP Auth Source will start a secure TLS
|
|
session after connecting to the LDAP server. This requires your LDAP
|
|
server to support TLS.
|
|
|
|
2.7.11 Require User (one per line)
|
|
|
|
The require user directive specifies what usernames can access the
|
|
resource. Once LDAP Auth Source has retrieved a unique DN from the
|
|
directory, it does an LDAP compare operation using the username
|
|
specified in the require user to see if that username is part of the
|
|
just-fetched LDAP entry. Multiple users can be granted access by
|
|
putting multiple usernames in the box, separated with newlines. For
|
|
example, with a AuthLDAPURL of ldap://ldap/o=XUF?cn (i.e., cn is used
|
|
for searches), the following require entries could be used to restrict
|
|
access: The Jester Fred User Joe Manager
|
|
|
|
Because of the way that LDAP Auth Source handles this directive, The
|
|
Jester could sign on as The Jester, Zen Jester or any other cn that he
|
|
has in his LDAP entry. Only the single require user line is needed to
|
|
support all values of the attribute in the user's entry.
|
|
|
|
If the uid attribute was used instead of the cn attribute in the URL
|
|
above, the above three lines could be;
|
|
|
|
tj
|
|
fred_u
|
|
jmanager
|
|
|
|
2.7.12 Require Group (one per line)
|
|
|
|
This directive specifies an LDAP group whose members are allowed
|
|
access. It takes the distinguished name of the LDAP group. For
|
|
example, assume that the following entry existed in the LDAP
|
|
directory:
|
|
|
|
dn: cn=Administrators, o=XUF
|
|
objectClass: groupOfUniqueNames
|
|
uniqueMember: cn=The Jester, o=XUF
|
|
uniqueMember: cn=Fred User, o=XUF
|
|
|
|
The following directive would grant access to both Fred and Jester:
|
|
|
|
require group cn=Administrators, o=XUF
|
|
|
|
Behavior of this directive is modified by the Group Attribute and
|
|
Group Attribute Is DN options.
|
|
|
|
2.7.13 Require DN
|
|
|
|
The require dn option allows the administrator to grant access based
|
|
on distinguished names. It specifies a DN that must match for access
|
|
to be granted. If the distinguished name that was retrieved from the
|
|
directory server matches the distinguished name in the require dn,
|
|
then authorization is granted.
|
|
|
|
The following directive would grant access to a specific DN:
|
|
require dn cn=The Jester, o=XUF
|
|
|
|
Behavior of this directive is modified by the Compare DN On Server option.
|
|
|
|
2.7.14 Default Manager
|
|
|
|
This allows you to specify the username of the Manager for this area.
|
|
The manager will still need to meet auth requirements above, but, if
|
|
they do they will get the 'Manager' role added to their list of roles.
|
|
|
|
2.7.15 Default Role
|
|
|
|
This is a role to be assigned to users when they auth correctly. This
|
|
is to differentiate them from merely being 'authenticated'.
|
|
|
|
2.7.16 Examples
|
|
|
|
* Grant access to anyone who exists in the LDAP directory, using their UID
|
|
for searches.
|
|
URL ldap://ldap1.zope.com:389/ou=People, o=XUF?uid?sub?(objectClass=*)
|
|
|
|
* The next example is similar to the previous one, but is uses the common
|
|
name instead of the UID. Note that this could be problematical if multiple
|
|
people in the directory share the same cn, because a search on cn must
|
|
return exactly one entry. That's why this approach is not recommended: it's
|
|
a better idea to choose an attribute that is guaranteed unique in your
|
|
directory, such as uid.
|
|
URL ldap://ldap.zope.com/ou=People, o=XUF?cn
|
|
|
|
* Grant access to anybody in the Administrators group. The users must
|
|
authenticate using their UID.
|
|
URL ldap://ldap.zope.com/o=XUF?uid
|
|
require group:
|
|
cn=Administrators, o=XUF
|
|
|
|
* The next example assumes that everyone at XUF who carries an
|
|
alphanumeric pager will have an LDAP attribute of qpagePagerID. The example
|
|
will grant access only to people (authenticated via their UID) who have
|
|
alphanumeric pagers:
|
|
URL: ldap://ldap.zope.com/o=XUF?uid??(qpagePagerID=*)
|
|
|
|
* The next example demonstrates the power of using filters to accomplish
|
|
complicated administrative requirements. Without filters, it would have
|
|
been necessary to create a new LDAP group and ensure that the group's
|
|
members remain synchronized with the pager users. This becomes trivial with
|
|
filters. The goal is to grant access to anyone who has a filter, plus grant
|
|
access to Joe Manager, who doesn't have a pager, but does need to access
|
|
the same resource:
|
|
URL ldap://ldap.zope.com/o=XUF?uid??(|(qpagePagerID=*)(uid=jmanager))
|
|
|
|
This last may look confusing at first, so it helps to evaluate what the
|
|
search filter will look like based on who connects, as shown below.
|
|
If Fred User connects as fuser, the filter would look like
|
|
|
|
(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))
|
|
|
|
The above search will only succeed if fuser has a pager. When Joe Manager
|
|
connects as jmanager, the filter looks like
|
|
|
|
(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
|
|
|
|
The above search will succeed whether jmanager has a pager or not.
|
|
|
|
|
|
2.8 General Items.
|
|
|
|
You can choose to use standard auth, or cookie auth, and you can
|
|
decide how long you want to cache the users credentials before
|
|
retrying.
|
|
|
|
2.8.1 Authentication Type
|
|
|
|
2.8.1.1 Standard Authentication
|
|
|
|
This method causes the browser to pop up a dialog box to ask for the
|
|
username and password.
|
|
|
|
2.8.1.2 Cookie Authentication
|
|
|
|
This method allows you to use a normal HTML form to get the username
|
|
and password from the user. It also will present the default form to
|
|
the user if they try to access an unauthorised area.
|
|
|
|
|
|
2.8.1.3 Secure Cookie based Authentication
|
|
|
|
This method, like Cookie Authentication allows you to use a HTML form
|
|
to get the user details. However, the cookie it uses does not contain
|
|
any login information. It is internally checked against a cache of
|
|
hashes and the information is derived from that. This cache disappears
|
|
if you restart Zope, so this is not a good option for people who want
|
|
to persistently cache logins across sessions.
|
|
|
|
|
|
2.8.2 Credential Cache Timeout in Seconds
|
|
|
|
exUserFolder by default caches credential information, so that the
|
|
authorisation source isn't hit *for every object and page* that has to
|
|
be fetched. For remote authentication services this can slow things
|
|
down quite considerably. Even setting this to a modest setting will
|
|
quicken response times.
|
|
|
|
Setting this too long could cause problems if you want to lock out a
|
|
troublesome user. The credential cache is flushed if someone provides
|
|
a password that doesn't match the one in the cache.
|
|
|
|
|
|
2.8.3 Negative Credential Cache Timeout in Seconds
|
|
|
|
exUserFolder allows you to cache login failures for users that do not
|
|
exist. This means you don't have to go out to your auth source when
|
|
you know for certain this user is never going to be able to
|
|
authenticate.
|
|
|
|
Due to the way some auth sources are designed, this doesn't work for
|
|
auth sources like SMB Auth Source that lie initially about the user
|
|
existing (because you can't verify the existence of a user without
|
|
authenticating them), and then check the credentials later.
|
|
|
|
It's possible to create a hybrid auth source that lets this work
|
|
correctly for auth sources that can't list the users.
|
|
|
|
|
|
2.8.4 Log out users who expire from cache?
|
|
|
|
If you've got caching turned on, then this will force any user who has
|
|
their session expire to login again. Some people like to do this.
|
|
|
|
|
|
2.8.5 Activate Session Tracking for anoymous users?
|
|
|
|
For any anonymous user, a new temporary user is created. This allows
|
|
you to set/get properties for anonymous users too. Currently
|
|
experimental.
|
|
|
|
|
|
3.0 PROPERTY SOURCES
|
|
|
|
4.0 MEMBERSHIP SOURCES
|
|
|
|
5.0 TIPS FOR THE UNWARY
|
|
|
|
Generally these things apply to Cookie Authentication models, since
|
|
there is additional access required to present the login form.
|
|
|
|
5.1 Too much protection.
|
|
|
|
A lot of people try to protect a folder by placing an exUserFolder
|
|
inside. They then change the permissions on this folder to only allow
|
|
Authenticated or some Local Role to have permission.
|
|
|
|
5.1.1 The problem
|
|
|
|
When you try to access the folder, instead of getting the form, you
|
|
get a popup box, even though you chose Cookie Authentication. Even
|
|
when you enter a username and password it doesn't work.
|
|
|
|
|
|
5.1.2 What happened
|
|
|
|
You tried to access an area you don't have access to. Zope found the
|
|
closest user folder to the object you were trying to access. The user
|
|
folder decided you were not authorised and tried to display the login
|
|
form. You don't have access to view the login form, so Zope finds the
|
|
nearest user folder to the login form, which is the user folder above
|
|
the protected directory. It pops up the authentication dialog. If you
|
|
put in a valid username and password for this top level, then lower
|
|
level then displays the login form.
|
|
|
|
5.1.3 Solution 1 (preferred).
|
|
|
|
Place the user folder one level *above* the folder you want to protect,
|
|
that is in the unprotected area. Everything should work fine.
|
|
|
|
5.1.4. Solution 2 (not so preferred).
|
|
|
|
Set the 'View' permission on the docLogin form inside the acl_users
|
|
folder. You can get there by Choosing 'Contents' on docLogin and
|
|
scrolling down to the bottom.
|
|
|
|
6.0 MISCELLANY
|
|
|
|
6.1 Adding an exUserFolder from a product.
|
|
|
|
You can add an exUserFolder from a Python product fairly easily, if
|
|
not a tad messily.
|
|
|
|
|
|
from Products.exUserFolder.exUserFolder import manage_addexUserFolder, eUserFolder
|
|
|
|
manage_addexUserFolder(authId='zodbAuthSource', propId='zodbPropSource',
|
|
memberId='basicMemberSource',
|
|
cookie_mode=1, session_length=600, REQUEST)
|
|
|
|
Obviously change authId, propId, and memberId to what you want.
|
|
However, you'll need to ram in the appropriate form fields for the various
|
|
source constructors into your REQUEST.
|
|
|
|
6.2 Session Tracking.
|
|
|
|
Session tracking (currently) relies on having the credential cache
|
|
active, and a property source active. Your trackable user will only
|
|
last as long as they are not expired from the cache. You should set
|
|
the cache expiry length to be somewhat longer than normal if you plan
|
|
to use Session Tracking, and you should also be prepared to check that
|
|
the current session is valid.
|