in reply to mod_perl and multiuser global variables

The problem is that
our $status = hiGuiStatus->new();
our $userid = $status->get_ldap_user_name();
get set by one user (the user that first generates the page), and then when the next user looks at the page they will see the info for the first user. Then since there are several servers (instanses of httpd) running it seems to switch from user to user as you reload the page.

To fix this set $userid in the handler.

-- gam3
A picture is worth a thousand words, but takes 200K.
  • Comment on Re: mod_perl and multiuser global variables

Replies are listed 'Best First'.
Re^2: mod_perl and multiuser global variables
by wazzuteke (Hermit) on Dec 05, 2005 at 15:33 UTC
    I would imagine this is a Apache child problem. I'll try to expalin:

    Apache is inheritedly and relitively multi-threaded. And, depending on your configuration and such, you will expect to have many threads open at any given time. The threads are usually called 'Children' or 'Apache Children'. Each of these children are used to load pages and send the data back to the requestor.

    Given this quick tutorial, it sounds to me like you are loading the LDAP user name globally to each child. Then when the user goes to the next page, the page is loaded through another child that is no longer aware of the $userid. However, in the same sense, the $userid is still defined, however in another child. Therefore, when another user comes along and loads the page, if they grab the same child as the user before them did, they would already have the $userid from the last user.

    Generally speaking, this is not the best way to hold persistant session data. Mainly because Apache, and all web servers for that matter, do not have the ability to uphold any type of persistance via the net. Perhaps the best way to hold this type of information in a semi-secure and easily retrievable way is through the assignement of a cookie or other persistance mechagnism.

    Answer:
    Don't use Perl variables within a Child to store user session information. It will, almost certainly, be shared to different requestors as the uptime of the server continues to grow.

    These might give you some more answers, too. Take a look at them in the order I've listed them:
    Good Luck

    ---hA||ta----
    print map{$_.' '}grep{/\w+/}@{[reverse(qw{Perl Code})]} or die while ( 'trying' );
Re^2: mod_perl and multiuser global variables
by ikegami (Patriarch) on Dec 05, 2005 at 15:21 UTC

    hum... If it wasn't in the handler, than none of the code would execute (since it's all at the same level), and he'd see nothing at all (or rather a 500 HTTP error). I suspect he's using Apache::Registry, in which case the code *is* in the handler.

    With Apache::Registry, the script gets converted to a function which is called every time the page is requested.

    I bet the problem is in his hiGuiStatus module.

    By the way rsennat, our isn't needed here. my will suffice and it would be a better choice here. The problem in the previous thread is that you were using a my variable as a global, which is a no-no in mod_perl. Here, they're not used as globals.

      hi,
      i need this to be resolved. because there is no persistency in getting the logged in user's info.

      this code is in a separate .cgi file and not in a handler to execute from the browser, which will display the user's info.

      im using PerlResponseHandler ModPerl::RegistryPrefork in httpd.conf.

      Only in mod_perl i see this problem. Even in perl/cgi environment im using the module hiGuiStatus.pm, where there is no problem.

      thanks
      rsennat
Re^2: mod_perl and multiuser global variables
by rsennat (Beadle) on Dec 05, 2005 at 14:35 UTC
    Sorry if im asking the very basic. I have just started using mod_perl.
    So, where to set $userid??

    thanks