Given Lift's focus on security I envisioned that the POST URL would
contain a random element, to reduce the threat of fake PayPal
interactions. It is a small risk, but then it is the small risks that
usually allow a hacker in, eventually.
David said there was support for per session dispatch, which would
mean that URL could be set up before calling PayPal. Once the session
ended, or the transaction, you would remove the URL support after
PayPal responded, or not...
I would favour the PayPal support being able to live independently of
other lift modules, with some (one) StatefulSnippets as an example?
Marc
On 26/09/2008, at 7:34 PM, Tim Perrett wrote:
>
> Great feedback - thanks guys!
>
> I'll re-jig the PDT stuff to make it more like your suggestions.
>
> Regarding the IPN pay pal stuff - I was having a think about this and
> thought that it would be good to do something along the same lines of
> ajax_requst.
>
> For instance, when you configure IPN you have to specify a location on
> your server where paypal will send the post data regarding the
> transaction - if we had:
>
> /<context_path>/paypal_gateway
>
> Then we could do all the processing and return an object which had all
> the data already assigned onto it. Before I start to right a bunch of
> stuff, what do people think? I don't want to pollute LiftServlet
> unless I really have to - is there someplace else I can put it, or
> would that be most suitable?
>
> Cheers
>
> Tim
>
>
>
>
> On Sep 24, 4:48 pm, David Pollak <[EMAIL PROTECTED]> wrote:
>> Kris Nuttycombe wrote:
>>> If you're going to take that approach, why not just make the
>>> constructor or factory method ensure that the object is in a valid
>>> state to begin with? When I write immutable objects, they usually
>>> don't have any setters for that very reason. It doesn't make sense
>>> to
>>> me that one would construct a PayPal object in an unusable state.
>>
>> Agreed. The initial "builder" (no longer using the word
>> Constructor per
>> Viktor's suggestion) should vend an object that can be used. Any
>> additional state (e.g., useSSL) should return a new instance of a
>> mutated object.
>>
>> As to Viktor's suggestion, having a bunch of builder methods on an
>> object rather than an explicit constructor is the right way to go.
>> e.g.:
>>
>> trait PayPal {....}
>>
>> object PayPal {
>> def apply(....): PayPal = ....
>>
>> }
>>> Kris
>>
>>> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]>
>>> wrote:
>>
>>>> Tim,
>>
>>>> I like the work, but I tend not to like mutable data structures
>>>> (stuff with
>>>> properties that one sets.) I'd structure things such that the
>>>> PayPal
>>>> object's "setters" return a new, immutable instance of the PayPal
>>>> object, so
>>>> you're code would look like:
>>
>>>> val pp: PayPal = new
>>>> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>>
>>>> I'd also update the "execute" method so that it returns another
>>>> immutable
>>>> object that has current state rather than mutating the original
>>>> PayPal
>>>> object.
>>
>>>> Thanks,
>>
>>>> David
>>
>>>> Tim Perrett wrote:
>>
>>>> Thanks Derek :-) I have commited any code for ages, so its about
>>>> time
>>>> I did!
>>
>>>> My plan is this - once I get this roll out of the site im doing now
>>>> (which just needs PDT) done, I'll add the IPN functions to it. From
>>>> the docs, it looks pretty straight forward.
>>
>>>> You can configure a whole bunch of options like so:
>>
>>>> /* values can be "sanbox" or "live" */
>>>> var paypal: PayPal = new PayPal("sandbox")
>>>> /* self expanitory */
>>>> paypal.transactionToken = S.param("tx").openOr("")
>>>> /* set if you need to use SSL (changes port and protocol) */
>>>> paypal.useSSL = true
>>>> /* run the paypal transaction - either with a PDT payload or
>>>> IPN
>>>> payload */
>>>> paypal.execute("pdt")
>>
>>>> Anything else / different way of doing it people think I should
>>>> build
>>>> in?
>>
>>>> Tim
>>
>>>> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]>
>>>> wrote:
>>
>>>> Tim, you rock :)
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
