trac keep reload itself for each page refresh, after account manager plugin is enabled

[walty]

After the account manager plugin is installed, I found that Trac keep reloads after EACH page refresh. The following info sentence keeps showing up in the trac log file.

INFO: Reloading environment due to configuration change

And after hours of investigation, I found that it's mainly caused by the two places of account manager plugin. as mentioned ​here, the Trac would be reloaded whenever the config file is updated.

I found that in version 0.4.2 (the latest stable version), the config file is actually modified by account manager for each authentication, which is performed for every page refresh.

web_ui.py:

415         if checkIPSetting:
416             self.env.config.set('trac', 'check_auth_ip', False)
417 
418         name = auth.LoginModule._get_name_for_cookie(self, req, cookie)
419 
420         if checkIPSetting:
421             # Re-enable IP checking
422             self.env.config.set('trac', 'check_auth_ip', True)
423 

and in guard.py:

 54     def __init__(self):
 55         # Adjust related values to promote a sane configuration, because the
 56         # combination of some default values is not meaningful.
 57         cfg = self.env.config
 58         if self.login_attempt_max_count < 1 and \
 59                 self.user_lock_max_time != 0:
 60             cfg.set('account-manager', 'login_attempt_max_count', 0)
 61             options = ['user_lock_time', 'user_lock_max_time',
 62                        'user_lock_time_progression']
 63             for option in options:
 64                 cfg.remove('account-manager', option)
 65         elif self.user_lock_max_time < 1:
 66             cfg.set('account-manager', 'user_lock_max_time',
 67                     self.env.config.defaults().get(
 68                     'account-manager')['user_lock_max_time'])

Now, in order to skip this problem, I have to turn off the persistent session and set a value for login_attempt_max_count.

Please help check, thanks!

[Ryan J Ollos]

The latest stable version is 0.4.3. I think this may have been fixed already.

[walty]

I just downloaded and checked the latest stable version (accountmanagerplugin_0.11-r12708.zip) and trunk version (accountmanagerplugin_trunk-r12708.zip) from the ​download link, but the corresponding issues seems still there.

may be I overlooked something here?

[Steffen Hoffmann]

Hm, all that is not new and discussing the past. You'll find it with less verbose words in #10871, that caused [12609], maybe the two most relevant pieces you've been missing before creating this ticket. And already enough to close this ticket. If you're not convinced right-away, and I bet this will be the case, read on please.

Replying to walty8:

I just downloaded and checked the latest stable version (accountmanagerplugin_0.11-r12708.zip) and trunk version (accountmanagerplugin_trunk-r12708.zip) from the ​download link, but the corresponding issues seems still there.

The cited code about 'check_auth_ip' option in web_ui.LoginModule is there for ages and remains there, yes. Code in guard.AccountGuard is rather fresh, and unlike the aforementioned code passage it really did cause considerable havoc, so I had to apologize for the too lightly tested acct_mgt-0.4.2 release. But it has been obsoleted since 14-Feb-2013 as hinted by rjollos before.

may be I overlooked something here?

Sorry, but adding to the two bits of information I've already mentioned you missed the announcement at our mailing-list. You missed recent changes leading to removal of a rather tiny portion of code in current stable.

You should take a look at the changelog file in the source next to setup.py. You'll even fail to find the cited AccountGuard config clean-up magic in trunk. This is mostly due to work for #8930, that you obviously overlooked too, despite the fact, that it took more than a dozen changesets worth one month of development and dramatically changed the configuration admin panel for upcoming acct_mgr-0.5. If you gave it a try, you would have missed that too.

Just doing code review in the stable branch without looking at changesets (and my great changeset comments btw) you'll certainly have a hard time and need to look rather close to see the difference between some bad code (once) and still ok (now). Here is why:

A Trac environment reload is not triggered by a configuration change in general, no. It depends on what configuration you speak about. Keep in mind, that we deal with two different configurations: One, commonly referred to as trac.ini, the file, and the other, the effective configuration, cached in memory while an environment is loaded. It came from the file on environment load, but may have been changed considerably since that time.

The trick is, that you can modify current running Trac behavior a lot by changing options at run-time. Trac will continue to run or not, after each change, but never reload on its own. Only if you save your current settings back to file, the updated file write access time stamp will trigger the reload almost instantly - on next request.

Or: when I added some option rewriting to AccountGuard, it was no problem on its own, but too bad to use config.save() for making changes permanent, thus reloading and effectively reverting to an 'unsane' state again, you see?

[walty]

Thanks for the detailed explanation!

I am sorry that I did not dig out the #10871 before I fired this ticket. I have actually did a quick search over the ticket list, and I looked for the keyword of "reload" and "config" over the active ticket lists, but got no luck. (may be I should use the search box of trac page)

I just did a few more experiements, this is issue is confirmed to be solved. And I studied [12609] and found the corresponding "save()" around line 73 of guard.py, and I guess that explains everything.

[Steffen Hoffmann]

You're welcome. Glad you found it solved too. Your observation about the .save() is correct too.