Forum OpenACS Q&A: erroring out in ad_maybe_redirect_for

1: erroring out in ad_maybe_redirect_for_registration

Posted by Jonathan Ellis on 03/05/02 12:19 AM

I get errors like this around 1 in every 2k page views:

[04/Mar/2002:14:40:14][15972.6151][-conn1-] Error:
    while executing
"set user_id [ad_maybe_redirect_for_registration]"
    (file "/web/prod/www/bf2/train.tcl" line 98)
    invoked from within
"source $script"
    (procedure "ns_sourceproc" line 6)
    invoked from within
"ns_sourceproc cns687 {}"

I have no idea what is causing this; it happens apparently to random pages. Anyone seen anything like this? It seems odd b/c nothing in ad-security calls [catch] so I'd expect more of a stack trace here. (The reason it's occuring from inside a source call is I have a registered proc set up to serve pages from certain directories as though they were in the root of the server. Prettier that way, and I don't clutter the real root.)

2: Response to erroring out in ad_maybe_redirect_for_registration (response to 1)

Posted by David Walker on 03/05/02 12:45 AM

is "set user_id [ad_maybe_redirect_for_registration]" within a catch?

ad_maybe_redirect_for_registration issues a double return that could cause problems in that case. It happens after a redirect so your users should not see a problem because of this.

    # blow out of 2 levels
    return -code return

3: Upvar & uplevel are your enemies.... (tcl losage and ACS design) (response to 1)

Posted by Jerry Asher on 03/05/02 12:48 AM

Which version of the ACS?

I may be all off about this, but I have seen this before under OpenACS 3.2.5, esp. in an environment where I had transplanted some Classec ACS 3.4.10 code into the OpenACS libraries.

If I recall what I found it is that a lot of the ACS security code was written in much too clever a fashion, relying on an uplevel to set various "global" parameters in your tcl interp so that you didn't have to set them yourself (say via (array set (fn (return (list ...))))).

The problem is that the aD code that did this created a dependency that your call level at the time of the uplevel be a precise number of levels down (or up). (Since the call to uplevel is something like, uplevel *level number*). There are places where that dependency is broken, and when it is, and the global variables have not been set, I have seen routines that rely on those parameters to exist die, even within a catch.

Upvar and uplevel -- fooey -- talk about dangerous and stupid ways to break any piece of modularity in your code. Whatever was wrong with (defmacro ...) Mr. Ousterhout?

4: Response to erroring out in ad_maybe_redirect_for_registration (response to 1)

Posted by Cathy Sarisky on 03/05/02 12:49 AM

I see it too in my logs. Never seems to cause any complaints on the user end. Glad to know it isn't just me...

5: Response to erroring out in ad_maybe_redirect_for_registration (response to 1)

Posted by Stan Kaufman on 03/05/02 12:54 AM

This is interesting. I also saw it, and for no particular reason, I changed the

set user_id [ad_maybe_redirect_for_registration]

to two lines:

set user_id [ad_verify_and_get_user_id]
ad_maybe_redirect_for_registration

The errors went away.

6: Response to erroring out in ad_maybe_redirect_for_registration (response to 1)

Posted by Don Baccus on 03/05/02 03:25 AM

The difference between what Stan does and what ad_maybe_redirect_for_registration boils down to one thing, from my reading of the code:

a call to ad_script_abort.

This calls "ad_raise" to abort the script, which in turn interacts with the request processor which handles the ad_script_abort condition.

The error's probably being triggered in there under some conditions but I've not dug into the request processor all that deeply so don't know offhand what might be causing the problem.

As others have said, though, it comes after the ad_returnredirect so it won't affect your users.

Is it possible the "once every 2K or so times" corresponds to the frequency with which your users wander into such pages without being logged in?

7: Response to erroring out in ad_maybe_redirect_for_registration (response to 1)

Posted by Jonathan Ellis on 03/05/02 03:53 AM

Yup, I went to one of these pages w/o a cookie set and got this msg in the log. Nothing visible to the browser. That makes me feel better. :)

8: Response to erroring out in ad_maybe_redirect_for_registration (response to 1)

Posted by Jonathan Ellis on 07/12/02 08:09 PM

It's the "return -code return" in ad_maybe_redirect_for_registration that's the problem in OACS 3.2.5, as indicated by Stan's workaround. Changing this to "return -code return 0" makes the error in the caller's set statement go away.

Hard to imagine a less descriptive error message, for sure. :)

Forum OpenACS Q&A: erroring out in ad_maybe_redirect_for_registration