The only real solution is to create a different user folder
implementation that doesn't handle domain auth so stupidly. For
instance, designate a user as a "domain user" and keep users like this
around in a different data structure so you don't need to iterate over
all users to find one that matches the domain spec.
On Wed, 2003-06-18 at 17:07, Andrew R. Halko wrote:
> Any other suggestions on how to implement domain based access? Or is
> the only solution to make users create accounts and login. For a large
> organization, this is tough.
> Andrew R. Halko
> -----Original Message-----
> From: Chris McDonough [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 5:03 PM
> To: Andrew R. Halko
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Zope-dev] Domain Login Slowness at certain location
> On Wed, 2003-06-18 at 16:07, Andrew R. Halko wrote:
> > Hello All,
> > I set up an Intranet that is based on visitors IP Address. I made a
> > tutorial at Plone.org
> > (http://plone.org/documentation/howto/HowToDomainIntranet). Now my
> > problem is that I am experiencing a lot of slowness for someone that
> > within the domain, but it is only within this one location. So, if I
> > set the site to check my address and log me in, there is not slowness.
> > But if I change the site to log people in automatically if they have
> > ip address for the gateway at the location, it is very very slow
> > for all of them.
> > Does anyone know the processes that the domain attribute goes through
> > log people in? Or maybe have an idea what could cause it? I am
> > to diagnose and I am not sure what could cause it. It is the mixture
> > the automatic login and firewall or something else at the location.
> > ideas? Thanks
> The code to support this "domain auth" feature is perhaps the stupidest
> part of Zope.access control. I am disappointed that it is still
> supported. Here is the code to support this mode of authentication,
> ripped directly from the AccessControl.User module:
> # we need to continue to support this silly mode
> # where if there is no auth info, but if a user in our
> # database has no password and he has domain restrictions,
> # return him as the authorized user.
> if not auth:
> if self._domain_auth_mode:
> for user in self.getUsers():
> if user.getDomains():
> if self.authenticate(user.getUserName(), '',
> if self.authorize(user, a, c, n, v, roles):
> return user.__of__(self)
> So this means, in essence, on each request, *for each user in the
> system*, check if he he has domain restrictions, if so is able to get in
> to the site with a blank password. For a site with many users,
> iterating over each user, checking for his domain restrictions, and so
> on can take a long time. And note that this doesn't just happen on one
> request, it happens on *every* request. Worse, it doesn't just happen
> for requests that happen to come from the domain upon which you've
> placed domain restrictions, it happens for *all* requests except the
> ones that pass in auth credentials via HTTP (from people who have
> already presented a valid username/password). This is almost certainly
> the cause of the slowness you see.
> I have been trying to remove this feature for quite some time. I can
> see its utility but the implementation is just way too stupid to be used
> for anything but tiny user databases.
> One possible hack that might make things much faster *for the people in
> the domain you're trying to allow access from* is to make sure that the
> *first* user returned by getUsers is the user that has the domain
> restrictions and blank password. A simple way to do this is to name
> that user "AAAA User" (because the default user folder's getUsers sorts
> the users by the lexical order of their names). This way the loop above
> will at most be gone through once for browsers in the domains you
> mention in that user's domain spec.
> This will not be the case for anonymous users. They will go through the
> whole user database for every request and only fall off the end of the
> userlist once they've tested every user. It will thus be just as slow
> for them.
> - C
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -