Possible bug with ModPerl 1.25 and Escape_uri
Hello, I hope this is the right place to put this. I have some code that takes data from a database and encrypts it via Blowfish and CBC. Not a problem so far, the problems comes with sending it to the client. If i do this my $f=CGI::Cookie-new(-name = 'Ticket', -path='/', -value = $ciphertext ); warn --- $f --- ; return $f; (And i had assigned it into a tmp variable and then 'warned' to the apache-error.log) I get this --- Ticket=RandomIV%1F%BC%B8%0B%2C%408%8E%3Fg%B8%AD%1D%60j%D0O %BDW%DD%29%94%A5%01%5B%99G%00%16r%F6%CF%B6%E5%F7%BB%C1-%FF %D8%B9WjLULA%0D%15%BCAb%BAT%5C%EB%2CQ%3E4b2%B6%BF%84%C5%F7 %83W0pm%25%AC%E77%8F%C8B%BFJN%C0Id%1FI%A6%90%06%29A%93IR%A6%A0 %E8Z%7DM%8B%BAK%7F%84%F5%09F%FF%7F%C3%E3%C4k_%C7%E7%E2%7D8 %EA%DB%11%DFe%7B%C5%F0%E7%95%AC%AD%8B%D8%DBp%B9n%A4Co%A6%F1 %1B%F2%FF%0C%9D%5E%23%EFh1B%83g%07%A6%91%A8F%EBZ%BFUke%808%25T %7D%F5%89Vq%B4%B8%3D%FB%0C%9F%7D%C7%CAM%BA%7B%1Dph%9C%95-%1F %D5%DB%1D%93%E6C%07%C1%F5%FB%7E%27%A7%E3g%CA%1E%10T%94%09%1A %96%E3%5C%01%8E%0A%B3%02%B3%B8%26%F3%11%FDg%02%D2%3B%9E%3CP%19 %AE%2F%89%C9%D7%84%ED%B5%EE%D5l%AE%EF%0BK%DA%3D%F7E%5E%C6 %2BqI%40z%25%03%24%9F%22q%A3%25v%BC%13%AB%DF%1ES%B1RT%20F%BF %FA%DD%3D%9E%20%EE%DE%BE%15e%CA%1Ao%A9%D3%0E%7E%B6%08%B1 %CD%12%1A%7ES; path=/ --- apologies for the largeness of that string, but i wanted to show that it does indeed work as i had planned. Now, i had wanted to get rid off CGI from the mod_perl processes (makes it use jst that bit less memory) and I have converted most of it away, except when i do this (with the same string you will notice) my $t=escape_uri($ciphertext); warn -= Ticket=$t; path=/ =- ; return Ticket=$t; path=/; i get this very nice string instead -= Ticket=RandomIV%1f%bc%b8%0b,@8%8e%3fg%b8%ad%1d%60j%d0O %bdW%dd)%94%a5%01%5b%99G; path=/; =- Now, if i look at the string (and ignoring all the strange characters that slip through escape_uri) i cant help but notice that escape_uri 'breaks' on the character after %99G which, lo and behold, is %00 which says to me that for some reason CGI::Cookie does the 'right thing' in the case of Blowfish encrypted text, but escape_uri in mod_perl doesnt. Any pointers or 'your stupid' are, as always, welcome. Regards and thanks Stef (Apache version is 1.3.17, modperl 1.25)
Silly Question Not in the FAQ
Hello, Me again (sorry about this) and this is probably a silly question but, each of my Apache children load in CGI.pm at startup time (via the startup.pl method). The only problem is that the apache-error log grows due to the CGI.pm startup message (offline mode: enter name=value pairs on standard input). Now, how do i get these messages removed or not going to my logfile ? I have the latest CGI.pm from CPAN,along with perl 5.005 patch 3, mod_perl 1.24 and Apache 1.3.17 on a FreeBSD box. Its not 'mission critical' (obviously) but its jst one of those little 'niggling' things that i would like to know how to 'scratch'. Thank you as always. Stefs
HTTP_REFERRER and Mod_perl
hello, okay, this may be a silly configuration problem, but I would really like to know if its jst me with this problem. if it is, then i dont mind being hit around the hit and pointed to the appropiate place for further reading. I have setup Apache (1.3.14) to use mod_perl for all the perl scripts (.pl) on the webroot. Everything is working great, I have written my own authentication procedures against postgreSQL 7 and have also used the Apache::DBI. Thats not the problem. The problems arise when i try to use HTTP_REFERRER from the $ENV enviroment. All the other variables are set jst fine (HTTP_HOST, HTTP_ACCEPT, HTTPS) but no HTTP_REFERRER. What am I doing wrong to not 'obtain' this variable. it never shows up in the $ENV list. Is this an oversight of mod_perl (v1.24). I need this to stop people from typing in URLS or jumping to a location from a bookmark. If i cant do it this way, then I guess I will have to use the MD5 encrypted url checksum and do it that way. Thanks for your thoughts and input. Regards, Stefs
Re: HTTP_REFERRER and Mod_perl
John wrote:
I think your mispelling :
HTTP_REFERER , not HTTP_REFERRER
When in doubt run a check on your %ENV hash
foreach( keys %ENV ) {
print "$_ = $ENV{ $_ }\n" ;
}
you know.. thats the funny thing. I DO that. i have
changed the spelling of HTTP_REFERRER to HTTP_REFERER
but still i dont get this showing up in mod_perl. is this set via
another Apache module perhaps ? Is it okay to have the
mod_perl handle all the .pl files instead of mod_cgi ?
here is the $ENV sorted alphabetical, as you can see.
no HTTP_REFERER of any sort. frankly i am a bit stumped
by this.
GATEWAY_INTERFACE="CGI-Perl/1.1"
HTTPS="on"
HTTP_ACCEPT="image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
image/png, */*"
HTTP_ACCEPT_CHARSET="iso-8859-1,*,utf-8"
HTTP_ACCEPT_ENCODING="gzip"
HTTP_ACCEPT_LANGUAGE="en"
HTTP_CONNECTION="Keep-Alive"
HTTP_COOKIE="sessionid=NMqr%2Fl6Rilxfo;"
HTTP_HOST="chronozon.dyndns.org"
HTTP_PRAGMA="no-cache"
HTTP_USER_AGENT="Mozilla/4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386;
Nav)"
MOD_PERL="mod_perl/1.24"
thanks for you time
(and sorry my correct spelling ;)
regards,
Stef
Re: HTTP_REFERRER and Mod_perl
John wrote: Are you hitting the page directly? If so then you will not get a referer. You have to link to it from another page in order for that variable to be set. If the page is the first to load in the browser there is no referring page. Just a thought! no, thank you. it was a good question and it got me thinking. I use the meta tags to push the person through the custom authentication process. The thing that i notice is that all the pages that are 'during' and the first one thereafter (the main menu as it is) dont have this set. When i link, they do. So i guess the moral of the story here is that meta tag redirects DONT set the REFERER variable at all. which is good to know, but requires a bit of a hefty rewrite on my end, and lots of checking the request_uri. Whelp. thank you everyone. i cant believe it was that obvious, but at least i will(should) have it working shortly. satori and peace. Stefs
Re: Apache::DBI strategy/philosophy
Tim wrote: Now I want to do things "right" and am trying to understand Apache::DBI. Before looking at the module I imagined that it would work by providing a library of persistent connections. You would check a connnection out of the library, use it, and then put it back when you are done, like checking a book out of the library. If you disconnected the connection, you just wouldn't return it, and the pool would have to create a new connection for the next user. Hrrmm. In this case though how would you discern between a slow connection and a 'disconnect' on the clients side ?! As far as we are aware, you couldnt, unless you sent back some sort of message to the server in which case it may as well deal with the disconnection itself at that point. (jst our opinion ;) But this is not the way Apache::DBI works. Instead, if I understand correctly after glancing at the module this morning, two consecutive identical connect calls will return the same connection! Why isn't this a problem? Is the assumption that two different transactions will use different user/pwd combinations? Afaik (or afaict) apache::dbi seems to cache any connection by lp (login and passwd) and server host/dbname. This is fine for us here because everyone has a unique lp to the database anywayz. If you only use one for lp for all connections, then it doesnt really matter 'who has the handle' as long as its open for business surely ?! The dbi handle (in other words) doesnt block whilst in a cgi, which you seem to think it is doing. It _will_ (if i read this right) if you have a large select or fetchrow call, but otherwise the concurrency shouldnt really be a problem (its all a matter how of how quick/slow your queries are). personally, in our application here, the individuals do a lot of large transactions, and even though DBI might queue them up, it would cause unacceptable delays in processing time. of course, there are other things to worry about if everyone has a unique lp and more than once we have seen people advocating against this. your mileage may vary. Thanks np (if i am right ;) ^stefs^
