RE: Doing Authorization using mod_perl from a programmers perspective
FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: >The HTTP_USER_AGENT doesn't identify unique users. It only identifies the >browser type/version (assuming it hasn't been messed with). > > >--Joe Breeden >--- >If it compiles - Ship It! >Aranea Texo > >> -Original Message- >> From: Jon Robison [mailto:[EMAIL PROTECTED]] >> Sent: Friday, November 16, 2001 10:40 AM >> To: [EMAIL PROTECTED] >> Cc: Jonathan E. Paton; [EMAIL PROTECTED] >> Subject: Re: Doing Authorization using mod_perl from a programmers >> perspective >> >> >> fliptop wrote: >> > >> > Jon Robison wrote: >> > > >> > > The most relevant section for you is the Ticket system he >> describes. (I >> > > believe the section header says something about Cookies, >> but you'll know >> > > you have the right one when you see TicketAccess.pm, >> TicketTools.pm, and >> > > TicketMaster.pm. One nice addition is the ability to add >> encryption to >> > > the Ticket, and the fact that the author used an MD5 hash >> (of an MD5 >> > > hash!) in the cookie, so verification of the authenticity >> of the user is >> > > pretty solid so long as you leave in things like ip >> address, etc. which >> > > he uses in the cookie by default. (Although AOL and some >> proxy systems >> > > might cause this to be trouble). AND, he also uses a >> mysql db for the >> > >> > i have found that using the HTTP_USER_AGENT environment >> variable instead >> > of ip address solves the problem with proxy servers and the >> md5 hash. >> > anyone ever tried this as a simple workaround? >> >> I think one problem with that is that is fails to uniquely >> identify the >> person. >> >> Someone please tell me if I am wrong - does the USER_AGENT field get >> some kind of special serial number from the browser, or is it just a >> version identified? >> >> Best example - large company with 1000 PC's, all with same Netscape >> installed. How then does the HTTP_USER_AGENT field deliniate between >> PC's? >> >> --Jon >> > >
Re: DSO Issues
If we're collecting a list of things that don't work in a DSO build, add perl subs (via ). At least, they didn't work as of January of this year. On Tue, 27 Nov 2001, John Chia wrote: > On 27 November 2001 15:17 (-0500), Vivek Khera wrote: > > The *only* issue I encounter is a massive memory leak upon SIGHUP or > > SIGUSR to apache. > > Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP > it. > > -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Finding Consultants on adding Perl Modules
Hi: Do you have a list of consultants who have experience in adding Perl Modules to Apache? We have a business need for some modules, such as Storable, and would be willing to contract for them. Is there some mechanism in general for finding Apache consultants? There are other areas we could use some help in, but as you know, many people put Apache on their resume if they have even read your web site! I'd appreciate any help you could give on this. Byron Byron Stephen Lee Server Development Manager Telleo 4 North Second Street Suite 300 San Jose, CA 95113 phone (408) 792-5742 fax (408) 792-5795 email: [EMAIL PROTECTED]
@INC and use
I've been porting a CGI to mod_perl, and had it working. Then last night mod_perl and apache were upgraded and recompiled and it stopped working. The script parses the URL for a command name (ex: ?cmd=search) and then hands off the job to a different module (ex: search.pm). The path for this module is loaded as a library with the use command at the beginning of the module which dispatches all the different commands (use lib '/data/public/myapp/dev/lib';). The dispatcher parses the module name at during execution, not at compile time. >From the mod_perl guide: (http://perl.apache.org/guide/porting.html#Reloading_Modules_and_Required_F), it looks as if the use statment is only effective during compile time, and the @INC is reset to normal, which wouldn't include this path. Am I understanding this correctly? And if I am understanding this correctly, I'm curious why it was working in the first place. Steve Cochran Dartmouth College
Page contains no data error
I'm moving someone else's CGIs to run under mod_perl, and about 95% of the time they work. The other 5% of the time Netscape gets a "Document contains no data." error and the web page that should have been sent to the brower is written into the apache error log. No other error is given in the error log. This is running on Apache 1.3.12, perl 5.004_04, and mod_perl 1.24. I'm beginning to suspect that mod_perl and perl arn't playing well together, since mod_perl and apache were just upgraded. After a server process gives the error, all mod_perl requests (such as perl-status) that hit that process will get the same error. Any ideas what it might be or a better way to track it down? Steve Cochran
Re: Document Contains no data
I have a program which runs fine 90% of the time under mod_perl. About 10% of the time Netscape reports "Document contains no data". Looking at the socket traffic, the client receives an orderly release indication (T_ORDEL_IND = 132) on the socket and reponds with a orderly release request, which closes the socket. I've added some printing calls to determine how far it's getting in the script, even one on the first line. When it fails there are no warnings, none of the STDERR output shows up in the error log, and the html is still generated and output to the error_log. It seems like once the socket it closed, the script continues, but output to STDERR dissapears and STDOUT goes to the error log. Any ideas why the server is sending the orderly release indication or any ways to trace it? I've run the server in single process mode, but it still doesn't give any errors or warnings. I've tried on two different machines, both DECs, one running Perl 5.00404, Apache/1.3.12, mod_perl/1.24, the other running perl 5.00404, Apache/1.3.6, mod_perl/1.20. Steve Cochran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OFF] strace
I'm trying to debug an intermittant problem on a Dec Unix server, and have gotten to the point where I need to use strace. On Dec Unix, strace wants a module ID, not a process ID. Anyone here familiar with Dec Unix? Steve Cochran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
I've been following along with this thread with interest, expecially since I'm new to the mod_perl list and community (thanks for all the help so far!). I thought you might be interesed in a 'mod_perl newbie' opinion. Recently I was handed an online event calendar running under CGI and asked to get it to run under mod_perl to speed it up. I'm comfortable with perl, but by no means a guru. And this was the first time using mod_perl. In the past I've used several products which might be considered competitors to mod_perl: Web Objects and Cold Fusion. CF was horrible, I'm glad I didn't have to work with it for long. WO was very nice to work with, and it had all the ecommerce and transation logic needed to build a enterprise web application quickly. (None of my work has been in ecommerce, instead in the medical industry (patient data, lab results, etc) which has many of the same requirements). Installing: I've installed mod_perl twice in the last month. The first time was on Solaris and was quite painless. The second time was on RH 7.0, and was fairly painful. Took most of a day of futzing around to finally get it installed and working. I ran into two problems, first the unrecognized version of apache 1.3.14, and second when I had downgraded to 1.3.12 the new auto-configure part of apache was bypassing the standard Configuration file which mod_perl had inserted itself into, so Apache was building itself without mod_perl. As several others have said here, there is work which could be done in this area. My suggestions would be: - easier install in general (big red button approach is always nice) - make it easier (clear instructions too) on how to configure apache with mod_perl and other modules. The current 'big red button' only works if you have no other modules or already have them configured. - Instructions written for someone who knows nothing about mod_perl, and possible very little about unix. This is a general problem for all open source projects. With today's IT shortage, more and more sys admins are just power users who were promoted or sucked into duties because someone else left. If you want to catch their eye, make sure you talk at their level. I realize this can be a pain in you know where, and it's something that as you look to advocate you need to think about. "Do we want to target everyone, or should there be a minimum level or aptitude before we recommend someone installs this?" Anyone can walk into Staples these days and install Linux. If they have a decent distribution installing everything is easy. But even without a package manager like RH, apache is usually very painless to install. I know a number of non-profits who just have competent users maintaining a Linux server with apache, because for the most part it's trouble free. At worst they might have to restart the server. Technical Issues: The second problem I see with mod_perl is a technical one. Because of the design of mod_perl, debugging problems can be fairly involved. Is the problem my code? Or is it apache, or maybe mod_perl? Could even be perl for that matter. Take for example the problem I ran into recently. (Please don't take this as a rant just because I had problems, I'm happy with mod_perl. But I'm fairly capable around unix and compiling, instead imagine this happening to someone who wasn't that comfortable.) The event calendar works great under CGI, so I try it under mod_perl. It was written to work under mod_perl by a better perl programmer that I'll ever be (Jon Howell of Faq-o-matic fame) and is very well designed. It even worked under mod_perl with some minor changes like supplying the user/pass to the database since it wasn't running under cgiwrap any longer. And it worked! But only 90% of the time. The other 10% of the time, the client received no data, and the page generated by the script ended up in the apache log. After cleaning up one implicit database handle destruction warning the problem persisted, and I began to attempt to discover where the connection was being closed. So I did what any lazy programmer does, I added some print statements to send a note to STDERR. While these all showed up when the program worked correctly, when problem occured, the prints to STDERR dissapeared. But the html page was printed to the apache log, basicly standard error. So it looks like if the socket is closed, stderr dissapears, and stdout goes to the error log. So no pointers appeared in the log, which wasn't very helpful. Next attempt was to do some packet sniffing to see why the socket was closeing. Turns out that the web server sends an orderly release indication (T_ORDEL_IND = 132), so the client being a good citizen reponds with a orderly release request and there goes the socket. While my description of the problem was more in-depth that I meant it to be, my point is that now I'm left with the need to trace through system calls made by apache, mod_perl and my program to try and find wh
Re: Document Contains no data
--- Stas Bekman wrote: On 17 Nov 2000, Stephen A. Cochran wrote: > > I have a program which runs fine 90% of the time under mod_perl. About 10% of > the time Netscape reports "Document contains no data". Looking at the socket > traffic, the client receives an orderly release indication (T_ORDEL_IND = 132) > on the socket and reponds with a orderly release request, which closes the > socket. run it in single mode and attach to the process with strace(1) or truss(1) (depending on what you have). See the debug chapter in the mod_perl guide. --- end of quote --- Thanks for the suggestions from the list for this problem. The strace/truss probably would have helped solve the problem, too bad Digital Unix doesn't have either : ( After two months I finally tracked it down. Turns out that in an infrequently called sub to handle minor error conditions, there was a line "close STDERR". The comment from the author said it was to "kill any ugly errors that havne't made it out yet ...". Not really sure what he really wanted to do originally, but that was the problem. Anytime a process which had executed this code under mod_perl received another mod_perl request, the browser displayed the "Document contains no data" error due to the sequence of requests as described above in my original post. I just confirmed this with a short script which only does "close STDERR". Thought I'd post this in case someone else ever runs into this, or it's a bug. Not sure of closing STDERR is a common practice in CGIs, but maybe a gotcha for the porting guide. Steve Cochran
Can anyone help please
Hi everyone, I have to make the tracking of users who follow links to external sites possible, preferably indicating in specific logfiles when a new browser is opened for linking to external sites. We have tried proxy solutions, modifying Apache core modules and are considering scanning and parsing our Html on the fly. I understand that uri.c could be modified or changes could be made to the .htaccess file. The problem is it has to be fast and transparant, does anyone have any ideas??? Thanks in advance Steve Smith
RE: Can anyone help please
Gunther, The scenario is we have a corporate website which allow freelance maintainers to product branded areas, as those arease are not administered our apache server must modify their html pages on the fly and open a new browser window whilst logging to a distinct log file. More details please. Are you referring to an intranet where your users are inside and you want to track them (cuz you talk about being able to control their proxy?) or are you talking about some other scenario? At 10:24 AM 2/20/01 +, Smith, Stephen (ELS) wrote: >Hi everyone, > >I have to make the tracking of users who follow links to external sites >possible, preferably indicating in specific logfiles when a new browser is >opened for linking to external sites. > >We have tried proxy solutions, modifying Apache core modules and are >considering scanning and parsing our Html on the fly. > >I understand that uri.c could be modified or changes could be made to the >.htaccess file. > >The problem is it has to be fast and transparant, does anyone have any >ideas??? > >Thanks in advance > > > >Steve Smith __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
mod_ssl and deprecated SSLDisable
I built mod_ssl without any backward compatibility enabled, and that caused the mod_perl ``make test'' to fail, since SSLDisable is no longer recognized in this configuration. Simply removing the ``SSLDisable'' from the stanza in t/conf/httpd.conf line is sufficient for the tests to succeed, most likely since, in conjunction with the change in syntax, mod_ssl now defaults to disabled, and requires an explicit ``SSLEngine on'' directive before it starts making further demands of the httpd.conf file. My apologies if this is a well known issue. - Stephen P. Schaefer -- Find my public key at http://pgp5.ai.mit.edu Key fingerprint = E1 B6 97 1B 96 9F A1 D1 77 09 AA 90 4B 0F 91 CC PGP signature
