You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by Christoph Gröver <gr...@sitepark.com> on 2012/10/01 12:03:12 UTC

Accessing environment variables set by other modules

Hello list,

I'm trying to access the environment variable "REMOTE_USER" which is
set by the mod_auth_kerb module (at least I think so).

I tried it with two different code snippets, both are not working.

1. const char *remote = apr_table_get(r->subprocess_env, "REMOTE_USER");

2. char *remote = get_env("REMOTE_USER");

I also changed the hook that I have my code registered in, so that it
runs later than the mod_auth_kerb.
But still "REMOTE_USER" appears to be always empty.

What am I doing wrong? Someone point me in the right direction?

Thank you for your time.

Greetings


-- 
Christoph Gröver, grover@sitepark.com

Re: Accessing environment variables set by other modules

Posted by Christoph Gröver <gr...@sitepark.com>.
Hello Jeff,

> Sometimes envvars are set directly into subprocess_env (e.g., handling
> of SetEnv/SetEnvIf).  IOW, subprocess_env is the primary
> representation.
> 
> But the REMOTE_USER and HTTP request header variables are a
> representation of information stored elsewhere (r->user,
> r->headers_in), and that envvar representation is created just before
> running an external process.
> 
> A module should always look at the primary representation, in this
> case r->user.

Thank you for these statements. Will just use r->user now.

Thankful greetings.

-- 
Sitepark Gesellschaft für Informationsmanagement mbH
Rothenburg 14-16, 48143 Münster

Telefon: +49 251 482655-0, Telefax: +49 251 482655-55
http://www.sitepark.com
http://www.facebook.com/sitepark

Geschäftsführer: Thorsten Liebold
Amtsgericht Münster, HRB 5017

Re: Accessing environment variables set by other modules

Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Oct 1, 2012 at 7:34 AM, Christoph Gröver <gr...@sitepark.com> wrote:
>
> Hello Daniel,
>
>> Just a quick suggestion; Have you tried r->user ?
>
> Tak! Really a good suggestion. r->user is set if it's run
> in the fixup hook.
>
> I still would like to know if it's possible to access variables set by
> other modules, but for the current development it'll be sufficient.

Sometimes envvars are set directly into subprocess_env (e.g., handling
of SetEnv/SetEnvIf).  IOW, subprocess_env is the primary
representation.

But the REMOTE_USER and HTTP request header variables are a
representation of information stored elsewhere (r->user,
r->headers_in), and that envvar representation is created just before
running an external process.

A module should always look at the primary representation, in this case r->user.

>
> With kind regards.
>
> Christoph Grøver
>
> --



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Accessing environment variables set by other modules

Posted by Christoph Gröver <gr...@sitepark.com>.
Hello Daniel,

> Just a quick suggestion; Have you tried r->user ?

Tak! Really a good suggestion. r->user is set if it's run
in the fixup hook.

I still would like to know if it's possible to access variables set by 
other modules, but for the current development it'll be sufficient.

With kind regards.

Christoph Grøver

-- 

Re: Accessing environment variables set by other modules

Posted by Daniel Gruno <ru...@cord.dk>.
On 10/01/2012 12:03 PM, Christoph Gröver wrote:
> 
> Hello list,
> 
> I'm trying to access the environment variable "REMOTE_USER" which is
> set by the mod_auth_kerb module (at least I think so).
> 
> I tried it with two different code snippets, both are not working.
> 
> 1. const char *remote = apr_table_get(r->subprocess_env, "REMOTE_USER");
> 
> 2. char *remote = get_env("REMOTE_USER");
> 
> I also changed the hook that I have my code registered in, so that it
> runs later than the mod_auth_kerb.
> But still "REMOTE_USER" appears to be always empty.
> 
> What am I doing wrong? Someone point me in the right direction?
> 
> Thank you for your time.
> 
> Greetings
> 
> 
Just a quick suggestion; Have you tried r->user ?

With regards,
Daniel.