Your Site Listing for http://perl.apache.org/stories/ at BigWhat.com
Greetings, This note is in reference to your site listing for http://perl.apache.org/stories/ You can check your listing by simply clicking here: http://www.bigwhat.com/asp/s.asp?b=a&u=http://perl.apache.org/stories/ If any portion of your listing is missing or inaccurate your site will not appear in our search results for our more than 1 million search users per day. If the listing is not to your liking, you can edit it online now! Please check to make sure we have your site listed exactly as you would like our search engine visitors to see it. We want our users to be able to find you! Additionally, there are probably several other keywords or key phrases which relate to your site that are not currently included. Please feel free to add them to your listing. Thanks in advance and feel free to call us with any questions. We're here to help! The BigWhat.com Content Team www.BigWhat.com [EMAIL PROTECTED] "A Different Kind of Search!" If you would like to be removed from any future Bigwhat.com mailings, please click the link below and enter your email address. http://www.bigwhat.com/asp/remove.asp
Re: Concepts of Unique Tracking
On Fri, May 25, 2001 at 10:03:04AM -0700, Jonathan Hilgeman wrote: > Now, I'm assuming that Apache has full access to these incoming packets. > Therefore, they must also have access to this invisible identifier. Is it > possible to extract that identifier somehow by tinkering with Apache? Most NAT implemetations keep a hash of destination ports -> internal IP. To wit: > 1) Person behind the firewall sends out a request to a web server. Person _really_ establishes an outgoing TCP session with his NAT box. The NAT box notes his internal_IP:dest_port, sets up an outgoing TCP session to web server, notes it's own source port for that leg. > 4) The firewall receives the packets of data first, but now must send those > data packets to someone inside the firewall. Returning packets from the webserver come to that source port, NAT box looks up hash of: external_IP:source_port -> internal_IP:dest_port, and hands the packet in. > 5) The packets of data MUST have some unique identifier to let the firewall That would be the source port of the NAT box's outgoing connection. But: - each outgoing TCP connection from the internal host will use a different source port. - the request your web server is receiving may actaully (likely) be coming from a web cache somewhere. > > Jonathan > -- Brian 'you Bastard' Reichert<[EMAIL PROTECTED]> 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path
Re: Antwort: Re: Appending Sessionid to all the urls
From: <[EMAIL PROTECTED]> > any Proxy operator can do this with any non-SSL connection. One can spy session > ids in the URL, in the GET-parameters and the POST-parameters, also cookies and > basic auth passwords, also passwords in html forms - and every bit of data > that's send back. > > Oh, and firewall operators and router operators and all people on the same > physical network can do the same... You're right, you can never be secure without encryption. But will browsers reliably strip the HTTP_REFERER if you leave a secure page? If they don't, you would still have to pass all external links through one of your own scripts. I see this becoming a problem in a larger, heterogenous environment, because someone is certainly going to forget this protective curtain and just write a plain HTML link. And any attacker would of course try to provoke this. cheers, stefan
Re: credit card processing
The product you are asking about is Commerce Server, which includes the Creditor component, Apache, covalent_ssl, mod_perl, etc. http://www.covalent.net/products/commerce/ Hope that helps, Bill - Original Message - From: "Adam Prime" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 23, 2001 11:47 AM Subject: credit card processing > > I was looking through the mod_perl archives and saw a post from doug about a > credit card processing system called 'creditor' i looked on the covalent > web site, but i couldn't find any info. Did this thing ever see the light > of day? > > If not, what are some alternatives to it? i was forwarded this url > (http://www.paygateway.com/tech/perl_plug/), but sites without index pages > make me wonder. Any feedback would be appreciated. It would be especially > great if we would be able to bill in both US and Canadian Dollar's using the > same thing. > > TIA > Adam >
[ANNOUNCE] Apache::AuthzLDAP 0.60
The uploaded file Apache-AuthzLDAP-0.60.tar.gz has entered CPAN as file: $CPAN/authors/id/C/CG/CGILMORE/Apache-AuthzLDAP-0.60.tar.gz size: 9718 bytes md5: ee2f18984cea35f0c2c139c25a255526 No action is required on your part Request entered by: CGILMORE (Christian Gilmore) Request entered on: Sun, 27 May 2001 20:57:43 GMT Request completed: Sun, 27 May 2001 20:59:04 GMT Virtually Yours, Id: paused,v 1.74 2001/05/20 14:59:52 k Exp k Apache::AuthzLDAP is designed to work with mod_perl and Net::LDAP. This module authorizes a user against an LDAP backend. It can be combined with Apache::AuthenLDAP to provide LDAP authentication as well. See AuthzLDAP.pm pod for detailed documentation. $Id: README,v 1.1 2000/09/26 18:51:51 cgilmore Exp $ 2001-05-27 Christian Gilmore <[EMAIL PROTECTED]> o Deprecated generic variable naming in favor of module specific to reduce potential conflict with other auth modules: GroupAttrType -> AuthzGroupAttrType GroupAttrValue -> AuthzGroupAttrValue LDAPServer -> AuthzLDAPServer LDAPPort-> AuthzLDAPPort MemberAttrType -> AuthzMemberAttrType MemberAttrValue -> AuthzMemberAttrValue NestedGroups-> AuthzNestedGroups UidAttrType -> AuthzUidAttrType Original variable names are still accepted but will be removed on the next major release. This change allows for user information to be hosted on one LDAP while group information is hosted on another. o Made release 0.60 2001-01-08 Christian Gilmore <[EMAIL PROTECTED]> o Fixed bug regarding nested groups whose membership was by dn o Better handled of pre-1.26 set_handlers bugs o Made release 0.51 2000-09-26 Christian Gilmore <[EMAIL PROTECTED]> o Made first public release 0.50 $Id: ChangeLog,v 1.4 2001/05/27 20:50:07 cgilmore Exp $ Enjoy, Christian - Christian Gilmore Infrastructure & Tools Team Lead Web & Multimedia Development Tivoli Systems, Inc.
[ANNOUNCE] Apache::AuthenLDAP 0.60
The uploaded file Apache-AuthenLDAP-0.60.tar.gz has entered CPAN as file: $CPAN/authors/id/C/CG/CGILMORE/Apache-AuthenLDAP-0.60.tar.gz size: 8176 bytes md5: 07405d95c2e62f5ce20f3dc067317755 No action is required on your part Request entered by: CGILMORE (Christian Gilmore) Request entered on: Sun, 27 May 2001 20:57:29 GMT Request completed: Sun, 27 May 2001 20:58:49 GMT Virtually Yours, Id: paused,v 1.74 2001/05/20 14:59:52 k Exp k Apache::AuthenLDAP is designed to work with mod_perl and Net::LDAP. This module authenticates a user against an LDAP backend. It can be combined with Apache::AuthzLDAP to provide LDAP authorization as well. See AuthenLDAP.pm pod for detailed documentation. $Id: README,v 1.1 2000/09/26 18:27:36 cgilmore Exp $ 2001-05-27 Christian Gilmore <[EMAIL PROTECTED]> o Deprecated generic variable naming in favor of module specific to reduce potential conflict with other auth modules: LDAPServer -> AuthenLDAPServer LDAPPort-> AuthenLDAPPort UidAttrType -> AuthenUidAttrType Original variable names are still accepted but will be removed on the next major release. o Made release 0.60 2001-01-08 Christian Gilmore <[EMAIL PROTECTED]> o Added handling of blank userid input o Better handling of pre-1.26 set_handlers bugs o Made release 0.52 2000-09-26 Christian Gilmore <[EMAIL PROTECTED]> o Made first public releases 0.50 and 0.51 $Id: ChangeLog,v 1.5 2001/05/27 20:52:15 cgilmore Exp $ Enjoy, Christian - Christian Gilmore Infrastructure & Tools Team Lead Web & Multimedia Development Tivoli Systems, Inc.
getting started on mac osX - perl.conf
hello,
im trying to get started with mod_perl on macosX and have run into some
problems. hope someone can help with some of them.
im following the Stein/MacEachern book rather carefully ...
presently i am at the point where i need to load their small
startup-script which looks like this:
__
#!/usr/bin/perl -w
BEGIN {
use Apache ();
use lib Apache->server_root_relative('lib/perl')
}
use Apache::Registry ();
use Apache::Constants ();
use CGI qw(-compile :all);
use CGI::Carp ();
1;
_
1) according to the book there should be a perl.conf file where i should
add a couple of lines, however this file doesnt appear anywhere on my
system, why is that?
2) anyway if i run the script from the terminal i get a message saying i
forgot to load the Apache module - how can this be when i have a
perfectly running apache server and a seemingly properly build version
of mod_perl?
3) inside /usr/local/apache there is a conf directory containg different
configuration-files and other stuff- im not sure why they are there at
all when the one i use is placed inside /etc/httpd - again i guess that
perl.conf should be placed inside that conf directory?
4) is it not correct that the server root is /usr/local/apache
- or is it on macosX /library/webserver/documents or something similar?
thanks
allan
Re: macintosh osX - mod_perl install problems -> head - HEAD - setenv
thanks again i did something similar with that lwp-head before i read your reply, but somewhat more stupid: rm HEAD (!) in fact i have now tested mod_perl with only "ok"s and "skipped on this platform"s and installed as well with no complaints whatsoever. so i guess im almost there (im posting other queries just after this) allan Ken Williams wrote: > > [EMAIL PROTECTED] (allan) wrote: > >one thing: i have discovered that another problem i have had since > >upgrading to perl 5.6.1 might be interfering with the one in this topic > >(im not sure though - it is concerning setenv) > > > >look at this new fresh terminal window: > > > >[localhost:~] aju% which head > >/usr/local/bin/head > >[localhost:~] aju% which HEAD > >/usr/bin/HEAD > >[localhost:~] aju% setenv LC_ALL C > >[localhost:~] aju% setenv LANG "en_US" > >[localhost:~] aju% which head > >/usr/bin/head > >[localhost:~] aju% which HEAD > >/usr/local/bin/HEAD > > Criminy! I don't understand this one bit. But if you do: > > cd /usr/local/bin > mv HEAD LWP-HEAD > > then you should have it out of the way for good. At least until you try > to upgrade LWP. =)
Re: macintosh osX - mod_perl install problems -> head - HEAD - setenv
[EMAIL PROTECTED] (allan) wrote: >one thing: i have discovered that another problem i have had since >upgrading to perl 5.6.1 might be interfering with the one in this topic >(im not sure though - it is concerning setenv) > >look at this new fresh terminal window: > >[localhost:~] aju% which head >/usr/local/bin/head >[localhost:~] aju% which HEAD >/usr/bin/HEAD >[localhost:~] aju% setenv LC_ALL C >[localhost:~] aju% setenv LANG "en_US" >[localhost:~] aju% which head >/usr/bin/head >[localhost:~] aju% which HEAD >/usr/local/bin/HEAD Criminy! I don't understand this one bit. But if you do: cd /usr/local/bin mv HEAD LWP-HEAD then you should have it out of the way for good. At least until you try to upgrade LWP. =) >maybe i should just start all over, reformat and everything ...? > No, that's probably a bit too drastic if you've got anything of consequence on the disk. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: macintosh osX - mod_perl install problems -> head - HEAD - setenv
Ken Williams wrote: > > [EMAIL PROTECTED] (allan) wrote: > >im aware of the head/HEAD problem that comes with LWP on mac osX and > >have therefore copied a binary head that ken williams sent me into > >/usr/bin and moved the lwp head into /usr/local/bin. > > Looks like that problem still isn't fixed, as shown by the following > error message: > > >Usage: head [-options] ... > >-muse method for the request (default is 'HEAD') > > You may have a different PATH than I do, or different capitalization on > the binary files. The upshot is that when you run the 'head' command, > it *must* run the /usr/bin/head program I sent you and not LWP's 'HEAD' > script. Here's a transcript from my shell, what does yours say? > >[localhost:~] ken% which head >/usr/bin/head >[localhost:~] ken% which HEAD >/usr/local/bin/HEAD hi ken thank you for the pointer but this head file is really going on my nerves ,-) one thing: i have discovered that another problem i have had since upgrading to perl 5.6.1 might be interfering with the one in this topic (im not sure though - it is concerning setenv) look at this new fresh terminal window: [localhost:~] aju% which head /usr/local/bin/head [localhost:~] aju% which HEAD /usr/bin/HEAD [localhost:~] aju% setenv LC_ALL C [localhost:~] aju% setenv LANG "en_US" [localhost:~] aju% which head /usr/bin/head [localhost:~] aju% which HEAD /usr/local/bin/HEAD one thing is certain even if dont use the setenv command: the file called head inside /usr/bin is definetely the binary you sent me the file called head inside /usr/local/bin is definetely the LWP one inside these directories there are definetely only one head file (ie there is no room for another with another capitalization) nevertheless when i try to build mod_perl i will get the annoying: Usage: head [-options] ... -muse method for the request (default is 'HEAD') maybe i should just start all over, reformat and everything ...? thanks once again allan
