Re: Re: Redirect to an external site on the serverside

[Gareth <g0...@yahoo.co.uk>]

Thanks Sam,

I've been doing a lot of reading around this issue, and that is essentially what my colleagues and I came up with.  Sadly the payment servers don't seem to support this (correct me if I'm wrong anyone), and also, don't seem keen to reply to my emails surrounding the issue (though they were quick enough with simple issues).

I was thinking of getting around the issue by performing the connection to their server myself from the server via XML-HTTP, but this seems very dodgy since I would need to update my server app whenever they do if I were to avoid my payment system suddenly breaking.

To be honest, I'm stunned that it can't be made secure - hence all my questions around the issue - I thought I was missing something crucial.

For reference, the affected payment providers are www.PayPal.com and www.NoChex.com.

Does anyone know of a service such as theirs that I can use in the UK for "free" (no monthly / annual charge).  I only want to take UK payments.

Kind Regards

Gareth



----- Original Message ----
From: Sam Gendler <sg...@ideasculptor.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Thursday, 30 November, 2006 7:40:51 PM
Subject: Re: Re: Redirect to an external site on the serverside

There is no way to tell a client to make a post request on redirect.
You can have your form submit directly to the bank, or you could
respond with a form full of hidden fields and include some javascript
that posts the form to the correct URL, but in general, security
through obscurity isn't security at all.  Sure, joe user probably
doesn't know how to alter the contents of a post, but any malicious
user will, so hiding the data in a post is not enough to prevent a
user from making changes to the data, anyway.  You must communicate
directly over a secure channel if you want to get info from your
server to someone else's server.  Otherwise, anyone with control of
the client in the middle can modify your communication.

If your payment server doesn't offer some method of controlling the
data it will receive that isn't susceptible to man in the middle
modificaton, get a different payment server.  I'd think they'd at
least provide a hash field where you can store the hash of the values
being sent.  Then, if they are changed, the hash won't match.  If you
use a secret seed for the hash, it would be pretty hard to fake,
depending on the has mechanism used.  An even better alternative would
be to encrypt the fields or the entire query string.

--sam


On 11/30/06, Cyrille37 <cy...@gmail.com> wrote:
> Gareth a écrit :
> > Thanks Marcus.
> >
> > I considered that solution, but the main issue is that I'm trying to make an (I think) insecure mechanism of taking a payment more secure by removing the ability for a malicious user to manually change the form variables clientside before it gets submitted to the payment server.
> >
> Hi,
>
> my 2 cents is that if you do not get any crypto signature mechanism
> between you and the bank, you could not let the client send information
> directly to the bank. Usually the bank provide a API to install on the
> server which you use to send information after you have checked client
> submition.
>
> regards,
> cyrille.
>
> >
> > ----- Original Message ----
> > From: "Marcus.Schulte@bmw.ch" <Ma...@bmw.ch>
> > To: users@tapestry.apache.org
> > Sent: Thursday, 30 November, 2006 10:21:39 AM
> > Subject: RE: Redirect to an external site on the serverside
> >
> > Hi Gareth
> >
> > in similar situations, I've used a custom form component. You can pretty
> > well just start using @Any for this. Then the client request goes
> > directly to the target site. Dowside is, if you calculate some of the
> > form fields on the server side, you might need some javascript stuff to
> > auto-submit the form ...
> > hth, Marcus
> >
> >
> >> -----Original Message-----
> >> From: Gareth [mailto:g01z@yahoo.co.uk]
> >> Sent: Thursday, November 30, 2006 10:35 AM
> >> To: Tapestry users
> >> Subject: Redirect to an external site on the serverside
> >>
> >> Hi,
> >>
> >> I've been trying to force a redirect to happen by throwing a
> >> RedirectException, and even injecting
> >> "tapestry.globals.HttpServletRequest" and forwarding it, but
> >> I can't find any way of forcing the redirect to contain the
> >> POST information from my page that was submitted.
> >>
> >> Is there any way?
> >>
> >> Essentially, I don't want to pass parameters to the external
> >> site  over the URL  because this would allow the user to
> >> manually change them.
> >>
> >> I've begun to wonder if the easiest way is to build my own
> >> request from scratch and sending it as if my server-side code
> >> were a browser, then somehow pass the response through to the
> >> client - essentially acting as a proxy I suppose, but only
> >> for the initial page retrieval... after that, my idea was the
> >> client's browser would talk direct to the external website,
> >> which incidentally is running in SSL (https) mode. Is any of
> >> this possible, and assuming it is, how would I go about doing it?
> >>
> >> Any Ideas?
> >>
> >> Many thanks.
> >>
> >> Gareth
> >>
> >>
> >> Send instant messages to your online friends
> >> http://uk.messenger.yahoo.com
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org






		
___________________________________________________________ 
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal 
http://uk.docs.yahoo.com/nowyoucan.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Re: Re: Redirect to an external site on the serverside

[Sam Gendler <sg...@ideasculptor.com>]

well, arguably, any solution that involves the client is going to be
just as fragile when it comes to 'api' changes from your payment
processors, since if the form fields change, you will have to update
your app, anyway.  You can't do it from the server, at least not
without proxying it and violating the user's security, since they will
need to log in to their paypal account in order to actually authorize
the payment, so you can't do it all at the backend.  At the same time,
I don't think there is anything stopping someone from changing the
payment amount somewhere else in the payment process, anyway.  Art
best, you can effect their landing page, but you have no control over
what they do with the rest of the transaction. It seems to me that
your only solution is to validate the amount paid via the paypal api,
and only release whatever it i you are selling after payment is
confirmed.  That way, they are free to mess with the payment amount,
but you are protected from giving away your merchandise for less than
the correct amount.

--sam


On 12/1/06, Gareth <g0...@yahoo.co.uk> wrote:
> Thanks Sam,
>
> I've been doing a lot of reading around this issue, and that is essentially what my colleagues and I came up with.  Sadly the payment servers don't seem to support this (correct me if I'm wrong anyone), and also, don't seem keen to reply to my emails surrounding the issue (though they were quick enough with simple issues).
>
> I was thinking of getting around the issue by performing the connection to their server myself from the server via XML-HTTP, but this seems very dodgy since I would need to update my server app whenever they do if I were to avoid my payment system suddenly breaking.
>
> To be honest, I'm stunned that it can't be made secure - hence all my questions around the issue - I thought I was missing something crucial.
>
> For reference, the affected payment providers are www.PayPal.com and www.NoChex.com.
>
> Does anyone know of a service such as theirs that I can use in the UK for "free" (no monthly / annual charge).  I only want to take UK payments.
>
> Kind Regards
>
> Gareth
>
>
>
> ----- Original Message ----
> From: Sam Gendler <sg...@ideasculptor.com>
> To: Tapestry users <us...@tapestry.apache.org>
> Sent: Thursday, 30 November, 2006 7:40:51 PM
> Subject: Re: Re: Redirect to an external site on the serverside
>
> There is no way to tell a client to make a post request on redirect.
> You can have your form submit directly to the bank, or you could
> respond with a form full of hidden fields and include some javascript
> that posts the form to the correct URL, but in general, security
> through obscurity isn't security at all.  Sure, joe user probably
> doesn't know how to alter the contents of a post, but any malicious
> user will, so hiding the data in a post is not enough to prevent a
> user from making changes to the data, anyway.  You must communicate
> directly over a secure channel if you want to get info from your
> server to someone else's server.  Otherwise, anyone with control of
> the client in the middle can modify your communication.
>
> If your payment server doesn't offer some method of controlling the
> data it will receive that isn't susceptible to man in the middle
> modificaton, get a different payment server.  I'd think they'd at
> least provide a hash field where you can store the hash of the values
> being sent.  Then, if they are changed, the hash won't match.  If you
> use a secret seed for the hash, it would be pretty hard to fake,
> depending on the has mechanism used.  An even better alternative would
> be to encrypt the fields or the entire query string.
>
> --sam
>
>
> On 11/30/06, Cyrille37 <cy...@gmail.com> wrote:
> > Gareth a écrit :
> > > Thanks Marcus.
> > >
> > > I considered that solution, but the main issue is that I'm trying to make an (I think) insecure mechanism of taking a payment more secure by removing the ability for a malicious user to manually change the form variables clientside before it gets submitted to the payment server.
> > >
> > Hi,
> >
> > my 2 cents is that if you do not get any crypto signature mechanism
> > between you and the bank, you could not let the client send information
> > directly to the bank. Usually the bank provide a API to install on the
> > server which you use to send information after you have checked client
> > submition.
> >
> > regards,
> > cyrille.
> >
> > >
> > > ----- Original Message ----
> > > From: "Marcus.Schulte@bmw.ch" <Ma...@bmw.ch>
> > > To: users@tapestry.apache.org
> > > Sent: Thursday, 30 November, 2006 10:21:39 AM
> > > Subject: RE: Redirect to an external site on the serverside
> > >
> > > Hi Gareth
> > >
> > > in similar situations, I've used a custom form component. You can pretty
> > > well just start using @Any for this. Then the client request goes
> > > directly to the target site. Dowside is, if you calculate some of the
> > > form fields on the server side, you might need some javascript stuff to
> > > auto-submit the form ...
> > > hth, Marcus
> > >
> > >
> > >> -----Original Message-----
> > >> From: Gareth [mailto:g01z@yahoo.co.uk]
> > >> Sent: Thursday, November 30, 2006 10:35 AM
> > >> To: Tapestry users
> > >> Subject: Redirect to an external site on the serverside
> > >>
> > >> Hi,
> > >>
> > >> I've been trying to force a redirect to happen by throwing a
> > >> RedirectException, and even injecting
> > >> "tapestry.globals.HttpServletRequest" and forwarding it, but
> > >> I can't find any way of forcing the redirect to contain the
> > >> POST information from my page that was submitted.
> > >>
> > >> Is there any way?
> > >>
> > >> Essentially, I don't want to pass parameters to the external
> > >> site  over the URL  because this would allow the user to
> > >> manually change them.
> > >>
> > >> I've begun to wonder if the easiest way is to build my own
> > >> request from scratch and sending it as if my server-side code
> > >> were a browser, then somehow pass the response through to the
> > >> client - essentially acting as a proxy I suppose, but only
> > >> for the initial page retrieval... after that, my idea was the
> > >> client's browser would talk direct to the external website,
> > >> which incidentally is running in SSL (https) mode. Is any of
> > >> this possible, and assuming it is, how would I go about doing it?
> > >>
> > >> Any Ideas?
> > >>
> > >> Many thanks.
> > >>
> > >> Gareth
> > >>
> > >>
> > >> Send instant messages to your online friends
> > >> http://uk.messenger.yahoo.com
> > >>
> > >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
>
>
> ___________________________________________________________
> Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal
> http://uk.docs.yahoo.com/nowyoucan.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org