Solved

Unable to deserialize value httpheader for product-subscription-key

Forum|Forum|7 years ago
February 15, 2018
3 replies
69 views

KDettman

I'm working on creating a REST service instance to connect to my company's Product Catalog. I successfully created one, but its SmartObjects don't return any data and throw the attached error, saying, "Unable to deserialize value httpheader."

I've found information about how to format a Authorization token in an httpheader, but I can't seem to find any information about how a product-subscription-key should be formatted.

I've also found informatiom about how to create the httpheader for a WCF Endpoint serice, but not for REST.

Any insight into this would be appreciated!

Best answer by KDettman

Thanks again for the response, Tin. It turned out I had missed a character at the end of our Product-Subscription-Key, so that was the issue.

K

KDettman
Author
Forum|Forum|7 years ago
February 15, 2018

Update: I used an Authorization header from another post as an example and crafted mine like this:

{"$type":"SourceCode.SmartObjects.Services.Endpoints.Common.HttpHeader[], SourceCode.SmartObjects.Services.Endpoints.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null","$values":[{"$type":"SourceCode.SmartObjects.Services.Endpoints.Common.HttpHeader, SourceCode.SmartObjects.Services.Endpoints.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null","Name":"Product-Subscription-Key","Value":"PRODUCT KEY WOULD BE HERE=="}]}

This stopped throwing the httpheader error, but now is throwing a 401 Access Denied error (see attached).

Does anyone know if that's still an issue with the httpheader product key being wrong or something else entirely?

Thanks!

Like

K

KDettman
Author
Forum|Forum|7 years ago
February 15, 2018

I don't believe that should be necessary, but it's a great thought. The following is info about the Product Catalog API's security models:

There are currently two different security models:

On-Premises Applications running within the bounds of the internal [company] network, which will have a [company] public IP, do not require the Authorization header. A valid subscription key header (Product-Subscription-Key) is still required for On-Premises applications in order to make requests to these APIs.

Off-Premises Applications outside of the internal [company] network--those with a non-[company] public IP--are required to authenticate via OAuth 2 with a JWT token using the Authorization header in addition to providing a valid subscription key header (Product-Subscription-Key).

My assumption is that because we have K2 Five installed on an on-prem server, this means we don't need an Authorization token. This is new to me, so let me know whether or not that makes sense.

Thanks for your time!