[ic] [timed-build] not working for logged in users

[Mike Heins]

Quoting Kevin Walsh (kevin at cursor.biz):
> Peter <peter at pajamian.dhs.org> wrote:
> > Then either that behavior should be fixed, or [timed-login] needs to be 
> > changed so that it checks something more reliable than $Vend::Cookie.
> > 
> > The next step would probably be to determine if there is any other code 
> > which relies on this strange behavior of $Vend::Cookie.
> > 
> The following patch works for me.  You can try it, but you should be
> aware that it could possibly cause unintended side-effects.  I have been
> running with the patch in since 21 March 2006 and haven't found any yet.
[patch snipped]
> As you can probably see, the $opt->{login} test is irrelevant if the
> flag is always cleared for logged-in users.
> 
> Using the "force" parameter causes session IDs to be stored in the
> timed-build cache file.
> 
> With the patch above patch, the following happens:
> 
>     * force=1 forces the cache to be built (if out of date) regardless
>       of whether or not that will cause session IDs to be included.
>       Only use that parameter if there are no internal links.
> 
>     * Users without a cookie-maintained session never get (or build)
>       the cache.
> 
>     * Non-logged-in users (with cookies) get (or build) the cache.
> 
>     * Logged-in users (with cookies and with login=1) get (or build)
>       the cache.
> 
>     * Logged-in users (with cookies and without login=1) never get
>       (or build) the cache.
> 
> That [timed-build] snippet has far too many negative tests for me to get
> my head around sometimes. :-)
> 
> I recommend the above patch, but haven't committed it to the core because
> concerns, within the icdevgroup, were raised about possible unknown
> side-effects.  As I said, it has been working for me.  It would be helpful
> if others could try it, in a non-critical environment, and report any
> problems they find.

If we get a couple more people using this with no deleterious effects,
we will commit it to the trunk. 

The hesitancy comes from the complexity of the session logic and past
experience with problems encountered monkeying with it. This is actually
bad, because it implies a "black magic" approach and a lack of understanding
of the internals.

In actual practice, I think we are OK to do the patch, as some of the cache
complexity has been removed from IC in the past two years as we realize
that it is not the proper place to do that type of performance improvement.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.647.1295  tollfree 800-949-1889 <mike at perusion.com>

Nature, to be commanded, must be obeyed. -- Francis Bacon