Re: mod_perl make failed: cannot find -lapr

[Stas Bekman <st...@stason.org>]

Randy Kobes wrote:
> On Tue, 31 Dec 2002, Steve Davis wrote:
> 
> 
>>Your help will be very much appreciated to resolve the
>>following issue. When attempting to make mod_perl.so, the make
>>script 'almost' makes a touchdown but fails before getting to
>>the finishing line.  Now it is time get some help from a coach.  
>>Hopefully, with a little help, a touchdown will soon follow.  
>>Below, I present was appears to be the problem, but someone
>>else will have to direct me to the next set of steps.
> 
> [ .. ] 
> 
>>This problem 'may' have to do with an issue of a change of
>>naming conventions which were adapted by the apr apache group.  
>>Confer with Stas Bekman's post on Nov 26, 2002 with a title of
>>"Problems compiling mod_perl 1.99_07 in RH 8.0".  He provides a
>>cvs patch; but, unfortunately, I'm not familiar with using
>>that-as least-as of yet. (Look's like I might have learn this
>>package real soon.)  Are they any intentions to update the
>>mod_perl-1.99_07.tar.gz?  If my conclusion is correct, then
>>currently, and according to the on-line instructions, the
>>present tar.gz edition is not compatible to the latest edition
>>of apache. (2.0.43).  So, 'maybe' the cause of my make failure.  
>>It appears as if, only the cvs repository maybe a valid for
>>compiling.  If my analysis is correct, and a new edition of the
>>respective non-cvs files be acquired somehow.
> 
> 
> It might be easier to obtain the whole mod_perl 2.0 sources
> via cvs, rather than patching - this is described at
> http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution
> You likely have a cvs client already, so it's a matter of
> changing to an appropriate directory and doing
> 
>  % cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
>  % cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co modperl-2.0

Or you can use the cvs snapshots tarballs, linked from the same URL 
Randy provided.

1.99_08 should be released RSN. I will make sure that it will state in 
the README file which Apache version it will work with.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

RE: [OT] Redirect POST to POST off-site?

[Rob Bloodgood <ro...@empire2.com>]

(sorry about the blank reply a minute ago)

> I am looking into the more advanced paypal instant notification
> stuff for the next version of my sw, but version one is using a
> simpler approach to get it out the door. Even that paypal sw
> wouldn't solve my problem, which is to make sure that the POST to
> paypal actually matches the transaction that the user has built up.

I found IPN to be *very* simple to use, logging the notifications to a DB
and then acting as required.  I would even be happy to send you my
notification script, which uses Apache::Registry but is really just a simple
POST BACK to paypal and when the response is 'OK', take the appropriate
action (payment received, account terminated, etc) (but please reply
privately if you want it).

The only nits I experienced were A) forgetting to send back the "OK\r\n" to
paypal that they expect to see from a successful notify.  They called me and
wondered if my script was broken... B) having to set up a unique index on my
logging table on the "verify_sign" field, because in spite of the correct
response chain, paypal has a tendency to notify repeatedly and redundantly.

HTH!

L8r,
Rob

Redirect POST to POST off-site?

[George Valpak <gv...@yahoo.com>]

Possibly off topic but I am not sure....

I have a page that contains a payment button for paypal which is essentially a form that gets POST'ed to paypal's https server.

I would like to do some processing on my end when the user clicks on that form.

My config is Apace 1.3.2x, MP 1.2x, Apache::Registry (all very recent but don't have the numbers handy here).

My idea is to replace the action on the form to point to my (non-https) web server, do my processing, and then redirect the request to paypal via 307.

My research seems to turn up that the appropriate RFC says the browser "MUST" confirm such a redirect with the user, which is no good for me on the server end (although I understand why on the client side).

I don't want to proxy the paypal server because:
	- it seems like a security issue, even if I use https
	- it probably violates paypal TOS

If it doesn't violate the TOS, I suppose I could just proxy the PayPal landing page and let paypal handle it from there. But I am hoping for a easier solution... any ideas?

I am looking into the more advanced paypal instant notification stuff for the next version of my sw, but version one is using a simpler approach to get it out the door. Even that paypal sw wouldn't solve my problem, which is to make sure that the POST to paypal actually matches the transaction that the user has built up. 

GV