Maintaining state is really something you need to build into the app, pesumbably Web Advisor. It seems to me probably the only way to do it effectively would be to make a wrapper app for Web Advisor. What you then do is insert your app between the end users and Web Advisor. You do what you want in your app then redirect to Web Advisor to do the actual work.

There are two ways to get this happening. Assuming WebAdvisor is a single.cgi you could just rename it WebAdvisor2.cgi and call your script WebAdvisor.cgi. A call to WebAdvisor.cgi will now go to you where you could in the first instance request the login and fire up a session cookie. Then you track the user via this cookie, logging as you want, and redirect to WebAdvisor to do the work.

That is the most simplistic model. You can also use the Apache mod_rewrite module to seamlessly direct request to your wrapper script. Need to aviod generating an infinite loop here but that is easy enough. Remember each request will now effectively be two part (first rewrites request to WebAdvisor to your script, you do stuff, then redirect to say dont-loop.cgi (does not even have to exist) because you get mod_rewrite to rewrite this to the real WebAdvisor.

The practical mechanics depend on the details but it is quite possible to insert your script into the chain of events. One gotcha is POST data. The usual login will probably be by POST. If you read this in your wrapper STDIN will be empty when the request gets to WebAdvisor. You could try passing the data in a query string or do a pipe open to WebAdvisor and pass the data you stole from STDIN to it that way. There are other ways within Apache to do it as well.

There are other possibilities such as using a proxy server but they are far more convoluted.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

You could write a simple mod_perl handler that looks at the URL being called, and the variables being POSTed or GETed. The easiest place to stick it would probably be at the FixupHandler stage. This gets executed right before the content is generated. In your case just before the CGI is called.

If you need to know what is being served up by the software as well (ie need to look at the resulting HTML from the CGI call), then you could look at the new Filter support in mod_perl2 (needs Apache 2.0.x). With that you can write a filter in perl that will recieve the HTML that was generated by the content handler (the CGI script in this case), and you can do what you like with it. You would probably want to parse it for any pertinant info, and pass it on unchanged...

If none of this helps, then maybe you could give us some more info, like what user info are you trying to track? And how is a user defined in the app (cookie, basic auth, url rewriting, hidden vars)? If the user is already being tracked by a cookie through the app, and you just want to know which users visit which URLs, then you could look at just adding a custom log rule to apache to track the URL and the cookie to a log file (see how the mod_usertrack module logs cookie values).

- Cees

use CGI;
$q = new CGI;
print $q->header, $q->hidden('variable', 'value'), .... ;
[download]