Community Feedback

So what do you think about this community of ours? Or Authorize.Net in general? Suggestions for improvement, as well as kudos on what you do like, are always welcome.

Reply
Posts: 321
Topics: 5
Kudos: 36
Blog Posts: 5
Ideas: 0
Solutions: 26
Registered: ‎11-09-2011

Request for Comments: API Best Practices

[ Edited ]

We just posted a draft of our upcoming API Best Practices Guide.

Please post your feedback below. Thanks!

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Regular Contributor
Posts: 55
Registered: ‎04-22-2011

Re: Request for Comments: API Best Practices

For example, in .NET 4.5, TLS 1.2 is enabled by default. Upgrading to .NET 4.5 should provide your solution with support for TLS 1.2.

 

That enables it in the platform, but you still need to interact with System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; to enable the use of TLS 1.2 (while keeping TLS 1.0 for other services you may contact that are not yet enabled for modern TLS) on outbound connections, somewhere in your application startup. By default, an HttpWebRequest or WCF client will use only SSL 3.0 and TLS 1.0 for outbound connections. (Inbound connections to your Windows server are controlled by registry settings which are easily managed by a tool called IIS Crypto and are independent of the .NET Framework version.) 

 

http://stackoverflow.com/a/29221917/32187

 

If you're unable to make code changes to your application to change the flags passed into SecurityProtocol, you can force all .NET applications on the machine to use TLS 1.2, 1.1, and 1.0 if available by setting a different registry setting.

 

http://stackoverflow.com/a/28502562/32187 and http://stackoverflow.com/a/34009938/32187

 

Hope this helps someone.

Member
Posts: 2
Registered: ‎02-18-2016

Re: Request for Comments: API Best Practices

npiasecki: I was about to post the same thing, nice post.  

 

The Best Practices article should be updated to remove this inaccurate text and say something of the following instead "In .NET 4.5, TLS 1.2 is supported, but NOT enabled by default.  You must set the SecurityProtocolType to enable TLS 1.2.

 

This is going to be a MAJOR issue come 2017 when Authorize.net disables TLS 1.0 and TLS 1.1 for probably 99% of .NET apps.

 

I can personally verify this is an issue since we've run into this exact same problem in a non authorize.net connection and you have to set the flags.  Here is another SO article to support:

 

http://stackoverflow.com/questions/28286086/default-securityprotocol-in-net-4-5

 

 

Posts: 321
Topics: 5
Kudos: 36
Blog Posts: 5
Ideas: 0
Solutions: 26
Registered: ‎11-09-2011

Re: Request for Comments: API Best Practices

@npiasecki @mikeada Thank you both for your feedback, and for the excellent point.

When that particular clause was added, it was because there was concern that the API Best Practices was very abstract, and it was hoped that adding that clause about .NET 4.5 would help provide a concrete example useful for developers. But your point is very valid, and we'll take that into consideration when making updates, prior to the final version.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Posts: 321
Topics: 5
Kudos: 36
Blog Posts: 5
Ideas: 0
Solutions: 26
Registered: ‎11-09-2011

Re: Request for Comments: API Best Practices

I've updated practice #3 with these specifics:

Note that you may need to make code changes to enable security features of the new security patches. For example, in .NET 4.5, TLS 1.2 is available by default. Upgrading to .NET 4.5, and adding “SecurityProtocolType.Tls12” to the System.Net.ServicePointManager.SecurityProtocol property, should provide your solution with support for TLS 1.2. Please consult your platform and framework documentation for more details. 

 

Thanks again for the feedback--and please let us know if you have any more comments or suggestions.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Member
Posts: 2
Registered: ‎02-18-2016

Re: Request for Comments: API Best Practices

Much better, thank you, that will hopefully save a lot of people some headaches.  It's not a well documented problem and Microsoft should probably make it the default IMHO.

Member
Posts: 2
Registered: ‎03-25-2016

Re: Request for Comments: API Best Practices

Dear,

I'm following this security update for our Authorize.Net integration, we're using ASP Classic to submit the service post_url = https://secure2.authorize.net/gateway/transact.dll as below:

                   Set objRequest = Server.CreateObject("MSXML2.ServerXMLHTTP")
                   objRequest.open "POST", post_url, false
                   objRequest.send post_string

I'm not clear too much about #3, #4, #5 in this article:

#3: Our OS is Window 2012 R2 , when we try to submit to Authorize test environment then it works

https://test.authorize.net/gateway/transact.dll

So do we need specify the security protocol like .Net in ASP? 

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 , if so can you provide the option in ASP?

#4: Our checkout feature process payment as above post, with type are CAPTURE_ONLY, CREDIT and VOID payment, that is called our production environment handles payment data? and do we need a DMZ?

#5: "Specifically, you must not count HTTP header lines to determine where the API response begins, as HTTP headers are subject to change without prior notice."-> sorry I'm not clear this too, with our above progress, what we need to update?

Thank you!

Posts: 321
Topics: 5
Kudos: 36
Blog Posts: 5
Ideas: 0
Solutions: 26
Registered: ‎11-09-2011

Re: Request for Comments: API Best Practices

[ Edited ]

Before I respond, I should make clear this is an API Best Practices document, not an API Requirements doc. While there are strong statements in this document, emphasized by "must" and "must not," it does not presume to cover every situation, and there may be situations when your solution cannot perfectly adhere to these practices.

Regarding your first question re: Practice #3 -- I'll need to do more research into this, as I am not an expert at ASP Classic. But I am somewhat dubious that ASP Classic allows for support of TLS 1.1 or TLS 1.2. Do any forum readers have better information at hand?

Please note that test.authorize.net currently accepts TLS 1.0, 1.1, and 1.2 connections, which means your solution could be using TLS 1.0. We are discussing when to disable TLS 1.0 in Sandbox and will have an announcement date at a later time.

Re: Practice #4 -- DMZs are required if you are handling payment information and storing it, whether in a temporary variable or a permanent database record. They're recommended if you're storing personally identifying information such as people's names, addresses, email addresses, phone numbers, etc. If you aren't storing any such information, there's no need for you to have a DMZ.

Re: Practice #5 -- Some create their own HTTP parsers in the code and make assumptions about how long, or how large, our HTTP headers are. If we make changes to the HTTP headers, their solutions break. If you are using a parser that's baked into your coding framework, there's a good chance that it properly handles headers by looking for the newline. And in that case, you don't have to do a thing differently.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Member
Posts: 2
Registered: ‎03-25-2016

Re: Request for Comments: API Best Practices

Dear, thank you a lot for your response, it's helpful for me, our system is already enabled TLS1.2 and disabled early TLS.

Member
Posts: 3
Registered: ‎08-26-2015

Re: Request for Comments: API Best Practices - test url?

I think our solution satisfies the TLS 1.2 and cipher requirements.

Operative word here is "think". It is a little scary that we don't know for sure.

Is there a test url we can try a simple post-response to make sure our solution satisfies the new cipher requirements before they go live?

 

Thank you for your attention,

Eric