Reply
Highlighted
Member
Posts: 7
Registered: ‎12-20-2010

Direct Post in a development environment, behind a firewall.

I've got Direct Post set up on a project.  I know it's necessary for the AuthNet servers to post back to my web server, but I'm developing on my laptop.  Even if I wanted to open my machine to the public, I have no static IP address and therefore present a bit of a moving target.

 

Can anyone suggest a workaround?  The only thing I can come up with is doing all my testing on the production server, which is risky and cumbersome.

 

 

Highlighted
Trusted Contributor
Posts: 451
Registered: ‎08-21-2009

Re: Direct Post in a development environment, behind a firewall.

In order to use DPM you will need to have a URL available so that Authorize.Net can return the transaction responses to you. This page will have to be publically accessible so that the connection can be made. If you do not have the ability of creating a page on your laptop which can be published you might consider obtaining a webhost for this purpose.

 

 

Thank you,

 

Elaine

Highlighted
Member
Posts: 7
Registered: ‎12-20-2010

Re: Direct Post in a development environment, behind a firewall.

That's not a great solution, though I understand the technical reasons behind it.  As your developers might be working from coffee shops, libraries, etc., where they have no control over inbound connections, it's not always feasible to make any portion of a PC accessible.  The idea of setting up a test site solely for testing one feature goes against the ethos of a good programming:  http://c2.com/cgi/wiki?LazinessImpatienceHubris

 

Two alternatives:

 

1) Create a very simple server program that developers can run on their systems that responds to basic requests.  Test requests can be directed to it instead of an outside server.

 

2) Publish a "best practices" guide that gives various alternatives for overcoming this obstacle.

 

I can't be the only one who is running into issues with this, and I can't be the only one dissatisfied with the approach you suggest.

Highlighted
Trusted Contributor
Posts: 165
Registered: ‎06-30-2010

Re: Direct Post in a development environment, behind a firewall.

I dont think it is fair to slam this setup - you are looking to integrate with a third party solution that is BASED on external facing servers.

 

Note the BASED - not all auth.net solutions are built on this method of operation - there are many that dont require this type of system setup.

 

But as a developer - to select this method which is specifically made to operate using external facing servers - then complain that it only runs on external facing servers really defies logic.

 

These days, remote development is regularly as transparent as local development. Between remote desktop access, virtualization and ftp - there are an abundance of options available. What is limiting your choices?

Highlighted
Member
Posts: 7
Registered: ‎12-20-2010

Re: Direct Post in a development environment, behind a firewall.

I'm not "slamming the setup".  I'm impressed with the idea behind it.

 

All I'm saying is, this makes local development impossible, so I encourage them to make a better product by providing support for the style of development that a lot of us do.

 

This doesn't seem hard.  They could add a controller to the published rubygem that fields test requests and mimics Direct Post responses.  That would keep everything local.  Or they could publish a simple program that listens on a local port that does the same thing.  The former would be easiest for the Ruby folks, but the latter would be useful to other developers.

 

Why am I choosing DPM rather than another solution more accessible to this development style?  DPM makes PCI compliance simple.  The Powers That Be demand PCI compliance.  I really have no choice in the matter.

 

 

>> What is limiting your choices?

 

Primarily, time.  I've had no reason to do remote development thus far, so I haven't.  If I can avoid adding that particular chunk of complexity, I would like to.  If that makes me an ignorant or crappy developer, then so be it.  I really wanted to be a lumberjack.

 

As I said, if they could give us a workaround that would allow for off-the-grid development, it would make the product better.  I'm sure they have a big punchlist of other features people want.  I'm just asking that this get thrown on the pile somewhere.

 

 

 

 

Highlighted
Member
Posts: 7
Registered: ‎12-20-2010

Re: Direct Post in a development environment, behind a firewall.

One workaround that didn't work:  I tried to set it up so that a post from my dev page

would get posted back to a url on the live site, where the response parameters would be stored.

From there, my browser was supposed to get redirected to a page on the live page as well, which

would send me a form that I could post back to the development site.

 

This doesn't work for the following reason:  If you're posting from localhost:3000, and asking it

to redirect to example.com/foo/bar, it replaces example.com with localhost:3000.  You can't have

the relay_response under a different domain.  Not sure if that applies to subdomains or not.

 

Perfectly understandable from a security standpoint, I suppose.

Highlighted
Member
Posts: 3
Registered: ‎10-28-2012

Re: Direct Post in a development environment, behind a firewall.

If you can configure your router (eg. at home) you can use NAT (http://en.wikipedia.org/wiki/Network_address_translation).
Highlighted
Member
Posts: 1
Registered: ‎03-05-2015

Re: Direct Post in a development environment, behind a firewall.

Use this: http://localtunnel.me

 

From a command line:

%> npm install -g localtunnel

%> lt --port 3001 --subdomain mysubdomain

 

 

The port is your local port - the public url you get will always be on port 80.

 

The custom subdomain so that you can set up an authorized relay in auth.net just once and not have to change it every time all the time.