Secure API links return error

[PNMIC]

I had the old USBase.php from 1-2 years ago and just updated to the latest one that says fixes ssl issue. With both TEST and Production modes, I get this error:

"80040B1AAPI Authorization failure. CityStateLookup is not a valid API name for this protocol.USPSCOM::DoAuth"

So I used the unsecure api links from the old USBase.php and it works fine, both test and production mode. These links are as follows:

const LIVE_API_URL = 'http://production.shippingapis.com/ShippingAPI.dll';
const TEST_API_URL = 'http://testing.shippingapis.com/ShippingAPITest.dll';

So unless there is something else wrong on my side, I don't think the SSL issue has been resolved. Unless USPS changed something...

[VinceG]

@PNMIC Thanks for reporting. looking at the documentation i can see that there are different links for production/test for different API calls.

in some cases it's production.shippingapis.com others it's secure.shippingapis.com not sure but i'll have to investigate to see what exactly the problem is.

[PNMIC]

Yep, yep, that's what I saw when I went to the web tools section of USPS. Too much data and not coherent. I think like Obamacare site, they probably just have one contractor working on it:)

So I just sent them an email minutes ago with my username, the new secure links per your latest script, and the old unsecured links from the original script, and I inquired with them if there is something wrong with the secure urls, is it different, or perhaps my account is not authorized for it...

Whatever the case, I'll post back here whatever info they send me.

Stay in touch!

[PNMIC]

Vince,

Just got a reply from USPS Web Tools division:

"Hello. The CityStateLookup API is an unsecured service and only works with http://production.shippingapis.com/ShippingAPI.dll.

Thanks,

Evan"

I think the only valid options here is:

a) Write code that uses unsecure link only for CityStateLookup.
b) Leave all links unsecured.

If we do A, then I'll contact USPS again and find out what other services that are unsecure only. Let me ask you this question, my site is SSL secure through out, wouldn't that be as good as using secure links for the API call?

Let me know which method (if any) you want done?

[VinceG]

@PNMIC i think the links should be static variables rather than constants, that way sub classes will be able to override them if necessary

[gborbonus]

How about an XML data sheet that you can maintain?

You could use curl to grab an initial datasheet, store it locally, then later make sure it doesn't need updating.

From that datasheet, use something along the lines of

class
<prod_url>PROD_URL</prod_url>
<test_url>TEST_URL</test_url>

I use the attribute method to make it easier for me to use preg_match and explode when the XML class is not available on the system. A fallback to handle it regardless of the extensions loaded.

[VinceG]

@gborbonus Not sure what you mean by xml datasheet. i was thinking something a lot easier and that won't have any BC issues.

[gborbonus]

Terminology is off. I just meant an XML file containing the configuration info.

The reason I suggest this method is that from this point forward, if the API changes or url's change, it's not a matter of updating the library, but updating the xml file(which you are maintaining directly), that way you can keep old versions working while developing features for new versions.

[VinceG]

@gborbonus not sure about the whole XML file config. i am not a big fan of those kind of configuration, especially with XML. Will have to look for the best solution. I don't think this will affect it in any way by breaking BC.

[narendratops]

using your library i get the class not found error.can u help me to integrate.i use directly demo.

[greggles]

I've asked them which APIs require HTTP vs. HTTPS. They got back saying that most are supported over HTTPS and only a few informational listings are not supported on HTTPS. I asked about this list specifically and hope to get an answer in a day or so, then we can move forward:

• RateV2
• RateV4
• IntlRateV2
• Verify
• ZipCodeLookup
• CityStateLookup
• TrackV2
• FirstClassMail
• SDCGetLocations

[greggles]

Here's their response:

RateV2 - Not actively supported
RateV4 - HTTPS, HTTP
IntlRateV2 - HTTPS, HTTP
Verify - HTTPS, HTTP
ZipCodeLookup - HTTPS, HTTP
CityStateLookup - HTTPS, HTTP
TrackV2 - HTTPS, HTTP
FirstClassMail - HTTP
SDCGetLocations - HTTP

So, I guess it's going to be necessary to have a per-method API endpoint.