[PHP] vend-bot?
OK, I want to send someone back from paypal to a thank you page; this reloads to the actual file they will purchase. BUT, I want to include a magic cookie that will prevent someone else from going to that url at a later time and getting the payload without paying for it. Any thoughts on how to build a secure vendobot? Let's discuss this in this thread. -- end Very Truly yours, - Kirk Bailey, Largo Florida kniht +-+ | BOX | +-+ think -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] vend-bot?
you always receive from paypal information (you should have something in $_POST or $_GET) so you can actually identify who it was, so it would be easy to simply say that if you don't have the information sent then you don't show the page. I don't recall exactly how this principal works but it was something like that. On 3 July 2011 18:32, Kirk Bailey wrote: > OK, I want to send someone back from paypal to a thank you page; this > reloads to the actual file they will purchase. BUT, I want to include a > magic cookie that will prevent someone else from going to that url at a > later time and getting the payload without paying for it. Any thoughts on > how to build a secure vendobot? Let's discuss this in this thread. > > -- > end > > Very Truly yours, > - Kirk Bailey, > Largo Florida > > kniht > +-+ > | BOX | > +-+ > think > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] vend-bot?
On 2011-07-03, at 1:32 PM, Kirk Bailey wrote: > OK, I want to send someone back from paypal to a thank ypage; this reloads to > the actual file they will purchase. BUT, I want to include a magic cookie > that will prevent someone else from going to that url at a later time and > getting the payload without paying for it. Any thoughts on how to build a > secure vendobot? Let's discuss this in this thread. > > -- > end > > Very Truly yours, > - Kirk Bailey, > Largo Florida > > kniht > +-+ > | BOX | > +-+ > think > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > What about generating a one time token for each transaction? Should be simple enough to manage. Bastien Koert -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] vend-bot?
ok, here's the deal; we sent someone to the paypal site for their purchase; the site will use the palpal shopping cart. When they come back, there needs to be a way to identify the product and the transaction so they an get the product ONCE. Now for a single purchase, we can just send them to (productname)thankyou.php and attach a magic cookie to the url as a query string. this magic cookie can only be used once. THIS WILL NOT WORK IF WE USE THE FULL SHOPPING CART AND THERE IS MORE THAN ONE PRODUCT TO DOWNLOAD, it only works with a buynow button for one only product. This kind of functionality, if worked out in detail, will lend itself to being adapted to MANY sorts of Eproducts, so I think there's an arguement to be made that this is of benefit to a significant segment of the php community. Well, at th4est them of us who like to get paid reliably, and not get ripped off. A ROUGH STAB AT HOW TO DO IT FOR SINGLE ITEMS As for one time only with buynow buttons: Send the customer to paypal with a cookie from the top of a list. When they come back, read the list's first entry. If it's there, make the download link available. the download is in a secured directory, a la Apache's directory securing methods. GIVE THEM THE PASSWORD. The user name is the magic cookie; tell them this. When they go to that page, apache demands the user name and password, which they give, and the page then (thanks to the query string having the item name) makes a download link available. This page also deletes that magic cookie from the list of them,so it can never be used again. Discussion? -- end Very Truly yours, - Kirk Bailey, Largo Florida kniht +-+ | BOX | +-+ think -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] vend-bot?
On Sun, Jul 3, 2011 at 9:17 PM, Kirk Bailey wrote: > ok, here's the deal; we sent someone to the paypal site for their purchase; > the site will use the palpal shopping cart. When they come back, there needs > to be a way to identify the product and the transaction so they an get the > product ONCE. Now for a single purchase, we can just send them to > (productname)thankyou.php and attach a magic cookie to the url as a query > string. this magic cookie can only be used once. THIS WILL NOT WORK IF WE > USE THE FULL SHOPPING CART AND THERE IS MORE THAN ONE PRODUCT TO DOWNLOAD, > it only works with a buynow button for one only product. > > This kind of functionality, if worked out in detail, will lend itself to > being adapted to MANY sorts of Eproducts, so I think there's an arguement to > be made that this is of benefit to a significant segment of the php > community. Well, at th4est them of us who like to get paid reliably, and not > get ripped off. > > A ROUGH STAB AT HOW TO DO IT FOR SINGLE ITEMS > As for one time only with buynow buttons: > Send the customer to paypal with a cookie from the top of a list. When they > come back, read the list's first entry. If it's there, make the download > link available. the download is in a secured directory, a la Apache's > directory securing methods. GIVE THEM THE PASSWORD. The user name is the > magic cookie; tell them this. When they go to that page, apache demands the > user name and password, which they give, and the page then (thanks to the > query string having the item name) makes a download link available. This > page also deletes that magic cookie from the list of them,so it can never be > used again. > > Discussion? > Only allowing them to access the URL once is a bad idea. If their download fails, is corrupt, or any number of other things go wrong (think accelerators, browser accelerators, etc) then you end up with a lot of support mail. Better to give them access for a short period of time. Personally I would generate a unique token linked to their account, or if no user system exists then link it to their order number. Stick that in a URL and forward them to it. That URL shows them the thanks page and links to download the product(s). Each of those links also contains the token. Expire that token after 24 hours, and on the page telling them it's expired give them a way to contact you just in case they haven't successfully downloaded the product yet. There is no need to use cookies. There is no need to use basic authentication (which is a horrible user experience). They come back from PayPal to a script that sets up their unique URL, then you take them to that URL. KISS it - the more complicated you make this the worse the user experience will be and it won't be any more secure than a time-limited unique token as described above. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] PHP EOL
Hello All,
Just so you know, this is not something I made up myself.
It was taken from an online HTML email tutorial.
Also, It has worked for years with no problem and I would still use it,
however I found out about the PHP_EOL and was just curious as to the
difference.
Thanks viraj...
Best,
Karl
On Jul 2, 2011, at 8:28 PM, viraj wrote:
hi all,
looking at the code Karl has posted, this code bit is not going to be
a help in setting the 'new line' character in an email body, because
it decides based on the server operating system.
if (strtoupper(substr(PHP_OS,0,5)**=='WIN')) {
$eol="\r\n";
when sending out emails, the most compatible way is to use "\r\n" as
Stuart has pointed out (plain text emails).
~viraj
On Sat, Jul 2, 2011 at 7:15 PM, Stuart Dallas wrote:
On Sat, Jul 2, 2011 at 9:01 AM, Karl DeSaulniers
wrote:
Hello All,
Happy pre independence for my American PHPers. And good health to
all
others.
Have a quick question..
I have this code I use for the end of line characters used in my
mailers.
[Code]
// Is the OS Windows or Mac or Linux
if (strtoupper(substr(PHP_OS,0,5)**=='WIN')) {
$eol="\r\n";
} else if (strtoupper(substr(PHP_OS,0,5)**=='MAC')) {
$eol="\r";
} else {
$eol="\n";
}
[End Code]
Does this suffice or should I be using the php supplied end of line?
$eol=PHP_EOL;
Or do these do the same thing?
What advantages over the code I use does the PHP_EOL have?
Or does it not matter with these and either are good to go?
It seems to me that they do the same thing.. am I on the right
track or
missing something?
Is there any other OS's that are not WIN or MAC and use the "\r"
or "\r\n"
?
If their are, then I can see an advantage of using the PHP_EOL.
Like I said, just a quick question. ;)
When you say "mailers" are you talking about emails? If so then
you should
be using "\r\n" at all times since that's what numerous email-
related RFCs
specify. If you use anything else then you may find your email
gets rejected
by strictly implemented mail servers (rare these days, but it
happens).
Incidentally, CR only applies to Mac OS9 and earlier. OSX uses LF
due to its
BSD roots. For a near-complete list, see "Representations" here:
http://en.wikipedia.org/wiki/Newline.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
Karl DeSaulniers
Design Drumm
http://designdrumm.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP EOL
On Sun, Jul 3, 2011 at 10:31 PM, Karl DeSaulniers wrote:
> Hello All,
> Just so you know, this is not something I made up myself.
> It was taken from an online HTML email tutorial.
> Also, It has worked for years with no problem and I would still use it,
> however I found out about the PHP_EOL and was just curious as to the
> difference.
>
You've checked that every single email it has ever sent has been received
correctly at the destination mailbox? The internet is built on RFCs, and
their general principle is "be strict in what you send and liberal in what
you accept" - if it wasn't like that the internet would fall apart. I
encourage you to do your part to do things right, but it's completely up to
you if you don't want to follow the users' manual.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
On Jul 2, 2011, at 8:28 PM, viraj wrote:
>
> hi all,
>> looking at the code Karl has posted, this code bit is not going to be
>> a help in setting the 'new line' character in an email body, because
>> it decides based on the server operating system.
>>
>> if (strtoupper(substr(PHP_OS,0,5)=='WIN')) {
>>
>>> $eol="\r\n";
>>>
>>
>> when sending out emails, the most compatible way is to use "\r\n" as
>> Stuart has pointed out (plain text emails).
>>
>>
>> ~viraj
>>
>>
>> On Sat, Jul 2, 2011 at 7:15 PM, Stuart Dallas wrote:
>>
>>> On Sat, Jul 2, 2011 at 9:01 AM, Karl DeSaulniers >> >wrote:
>>>
>>> Hello All,
Happy pre independence for my American PHPers. And good health to all
others.
Have a quick question..
I have this code I use for the end of line characters used in my
mailers.
[Code]
// Is the OS Windows or Mac or Linux
if (strtoupper(substr(PHP_OS,0,5)=='WIN')) {
$eol="\r\n";
} else if (strtoupper(substr(PHP_OS,0,5)=='MAC')) {
$eol="\r";
} else {
$eol="\n";
}
[End Code]
Does this suffice or should I be using the php supplied end of line?
$eol=PHP_EOL;
Or do these do the same thing?
What advantages over the code I use does the PHP_EOL have?
Or does it not matter with these and either are good to go?
It seems to me that they do the same thing.. am I on the right track or
missing something?
Is there any other OS's that are not WIN or MAC and use the "\r" or
"\r\n"
?
If their are, then I can see an advantage of using the PHP_EOL.
Like I said, just a quick question. ;)
>>> When you say "mailers" are you talking about emails? If so then you
>>> should
>>> be using "\r\n" at all times since that's what numerous email-related
>>> RFCs
>>> specify. If you use anything else then you may find your email gets
>>> rejected
>>> by strictly implemented mail servers (rare these days, but it happens).
>>>
>>> Incidentally, CR only applies to Mac OS9 and earlier. OSX uses LF due to
>>> its
>>> BSD roots. For a near-complete list, see "Representations" here:
>>> http://en.wikipedia.org/wiki/**Newline
>>> .
>>>
>>> -Stuart
>>>
>>> --
>>> Stuart Dallas
>>> 3ft9 Ltd
>>> http://3ft9.com/
>>>
>>>
> Karl DeSaulniers
> Design Drumm
> http://designdrumm.com
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[PHP] Re: [PHP-DB] Re: [PHP] PHP EOL
@Stuart,
Actually that is what made me look into the PHP_EOL Stuart. Wanting
to do things right.
Did you not read my initial email? I am not suggesting anyone adopt
my code.
The question was directed to what the differences are so I COULD
learn the right way.
Being that this was something I got off a tutorial from an accredited
website, your saying that to the wrong person.
I went and read the manuals and am here now posting the question so
as to get the right direction.
I have heard the argument and actually agreed. It would be better to
use the PHP_EOL instead.
I have been directed in the right direction. So I will be changing my
code to reflect.
Thank you,
Best,
Karl
A am going to end this thread here. Since it is getting cross-post
responses.
On Jul 3, 2011, at 4:37 PM, Stuart Dallas wrote:
On Sun, Jul 3, 2011 at 10:31 PM, Karl DeSaulniers
wrote:
Hello All,
Just so you know, this is not something I made up myself.
It was taken from an online HTML email tutorial.
Also, It has worked for years with no problem and I would still
use it,
however I found out about the PHP_EOL and was just curious as to the
difference.
You've checked that every single email it has ever sent has been
received
correctly at the destination mailbox? The internet is built on
RFCs, and
their general principle is "be strict in what you send and liberal
in what
you accept" - if it wasn't like that the internet would fall apart. I
encourage you to do your part to do things right, but it's
completely up to
you if you don't want to follow the users' manual.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
On Jul 2, 2011, at 8:28 PM, viraj wrote:
hi all,
looking at the code Karl has posted, this code bit is not going
to be
a help in setting the 'new line' character in an email body, because
it decides based on the server operating system.
if (strtoupper(substr(PHP_OS,0,5)=='WIN')) {
$eol="\r\n";
when sending out emails, the most compatible way is to use "\r\n" as
Stuart has pointed out (plain text emails).
~viraj
On Sat, Jul 2, 2011 at 7:15 PM, Stuart Dallas
wrote:
On Sat, Jul 2, 2011 at 9:01 AM, Karl DeSaulniers
wrote:
Hello All,
Happy pre independence for my American PHPers. And good health
to all
others.
Have a quick question..
I have this code I use for the end of line characters used in my
mailers.
[Code]
// Is the OS Windows or Mac or Linux
if (strtoupper(substr(PHP_OS,0,5)=='WIN')) {
$eol="\r\n";
} else if (strtoupper(substr(PHP_OS,0,5)=='MAC')) {
$eol="\r";
} else {
$eol="\n";
}
[End Code]
Does this suffice or should I be using the php supplied end of
line?
$eol=PHP_EOL;
Or do these do the same thing?
What advantages over the code I use does the PHP_EOL have?
Or does it not matter with these and either are good to go?
It seems to me that they do the same thing.. am I on the right
track or
missing something?
Is there any other OS's that are not WIN or MAC and use the
"\r" or
"\r\n"
?
If their are, then I can see an advantage of using the PHP_EOL.
Like I said, just a quick question. ;)
When you say "mailers" are you talking about emails? If so then you
should
be using "\r\n" at all times since that's what numerous email-
related
RFCs
specify. If you use anything else then you may find your email gets
rejected
by strictly implemented mail servers (rare these days, but it
happens).
Incidentally, CR only applies to Mac OS9 and earlier. OSX uses
LF due to
its
BSD roots. For a near-complete list, see "Representations" here:
http://en.wikipedia.org/wiki/**Newline
.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
Karl DeSaulniers
Design Drumm
http://designdrumm.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Karl DeSaulniers
Design Drumm
http://designdrumm.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [PHP-DB] Re: [PHP] PHP EOL
On Sun, Jul 3, 2011 at 11:22 PM, Karl DeSaulniers wrote: > @Stuart, > Actually that is what made me look into the PHP_EOL Stuart. Wanting to do > things right. > Did you not read my initial email? I am not suggesting anyone adopt my > code. > The question was directed to what the differences are so I COULD learn the > right way. > Being that this was something I got off a tutorial from an accredited > website, your saying that to the wrong person. > I went and read the manuals and am here now posting the question so as to > get the right direction. > I have heard the argument and actually agreed. It would be better to use > the PHP_EOL instead. > I have been directed in the right direction. So I will be changing my code > to reflect. > I meant no offence, I was simply responding to your comment: "Also, It has worked for years with no problem and I would still use it" ...and took it to mean you would have no issue with using that code, so I thought it worth pointing out that the standards exist for a reason. In the name of clarification, the "manual" I was referring to is the sum total of the RFCs that define the various protocols used on the internet, not the PHP manual which I believe you think I meant. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Re: [PHP-DB] Re: [PHP] PHP EOL
I see. Yes, I was referring to the PHP manual. I will investigate the RFC manuals as well like you had noted. No offense taken. Thank you for the clarification. Best, Karl On Jul 3, 2011, at 6:07 PM, Stuart Dallas wrote: On Sun, Jul 3, 2011 at 11:22 PM, Karl DeSaulniers wrote: @Stuart, Actually that is what made me look into the PHP_EOL Stuart. Wanting to do things right. Did you not read my initial email? I am not suggesting anyone adopt my code. The question was directed to what the differences are so I COULD learn the right way. Being that this was something I got off a tutorial from an accredited website, your saying that to the wrong person. I went and read the manuals and am here now posting the question so as to get the right direction. I have heard the argument and actually agreed. It would be better to use the PHP_EOL instead. I have been directed in the right direction. So I will be changing my code to reflect. I meant no offence, I was simply responding to your comment: "Also, It has worked for years with no problem and I would still use it" ...and took it to mean you would have no issue with using that code, so I thought it worth pointing out that the standards exist for a reason. In the name of clarification, the "manual" I was referring to is the sum total of the RFCs that define the various protocols used on the internet, not the PHP manual which I believe you think I meant. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ Karl DeSaulniers Design Drumm http://designdrumm.com
[PHP] VS.Php?
Hi All, Just wondering if anyone has any experience with VS.Php? I'm coming from C# job into a job where I will do mixed C# / PHP, and it would be good to be able to work in the IDE environment I'm already used to when working on PHP code. M is for Murray http://www.voodoologic.org
[PHP] Would like to subscribe to this mailing list
I would like to subscribe to this mailing list please. Thanks. Sincerely, Brian Dworkin Managing Partner Bright Telecom 201-892-9553 (mobile #) br...@brighttelecom.net http://www.brighttelecom.net -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-DB] Re: [PHP] Re: [PHP-DB] Re: [PHP] PHP EOL
Hello Stuart, After some closer look at the RFC Compliant manuals you suggested, I have determined that the creator of that code was in fact RFC821 Compliant. Being that this was a code I found several years ago, RFC822 may not have been in effect. This being the reason (I believe) that the creator went with a check for System OS when determining the end of line characters to use. Not substantiated in any way, but that is what it looks like to me. I could stand corrected. Best, Karl On Jul 3, 2011, at 6:11 PM, Karl DeSaulniers wrote: I see. Yes, I was referring to the PHP manual. I will investigate the RFC manuals as well like you had noted. No offense taken. Thank you for the clarification. Best, Karl On Jul 3, 2011, at 6:07 PM, Stuart Dallas wrote: On Sun, Jul 3, 2011 at 11:22 PM, Karl DeSaulniers wrote: @Stuart, Actually that is what made me look into the PHP_EOL Stuart. Wanting to do things right. Did you not read my initial email? I am not suggesting anyone adopt my code. The question was directed to what the differences are so I COULD learn the right way. Being that this was something I got off a tutorial from an accredited website, your saying that to the wrong person. I went and read the manuals and am here now posting the question so as to get the right direction. I have heard the argument and actually agreed. It would be better to use the PHP_EOL instead. I have been directed in the right direction. So I will be changing my code to reflect. I meant no offence, I was simply responding to your comment: "Also, It has worked for years with no problem and I would still use it" ...and took it to mean you would have no issue with using that code, so I thought it worth pointing out that the standards exist for a reason. In the name of clarification, the "manual" I was referring to is the sum total of the RFCs that define the various protocols used on the internet, not the PHP manual which I believe you think I meant. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ Karl DeSaulniers Design Drumm http://designdrumm.com Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
