While I don't have a good answer for your question, I'd like to point out that creating HttpClient for each request is considered bad practice and should be avoided. Better to create one instance and reuse
Do you think this might happen due to parallel requests using separate tokens over async call and might not get authorized? I'll try to make it into 1 call though to see if it works. In some random cases I get authorized and the call completes with appropriate token.
Could be. I'm not an Oauth expert (I should be), but it is possible that if you have parallel requests, the later token might invalidate the early one. It might also be a good idea to reuse the bearer token until it's expired (again, not an expert)
Thanks Quan. I'll give it a try. Though on my local environment I never had this problem. Do you have any example how to reuse the token?
It seems to have been resolved since I had the HttpClient instance at the constructor. That way it makes 1 instance of HttpClient and the authorize token (internally being generated within HttpClient).
I'm working with the support case related this thread.
Is problem still persist?
In your local developement, did you setup with https?
At the moment, I don't have any idea but I suggest a solution:
When Job has error, we will retry one more time: re get token and re-post
We've tried it earlier but the intermittent behavior is there. Could you please list out the must-have configuration settings on production? On local without/with https it works just fine.
You can find documentation here: https://world.episerver.com/documentation/developer-guides/Optimizely-Service-API/installation-and-configuration/
But I think it's not related configuration because as you said error occurs some points.
Could you change logic as I mentioned: when error occurs, job will retry one more time and log bug for that request?
We have tried re-running the job iteration when it throws an exception while generating the token request. There is no full stack trace except the message 'User is not authorized for this request'
What do you think might be the reason behind this error?
@Manoj can we see what authentication options you've setup on the Service API side?
I'm using EPIServer Service APIs to import products/catalog from xml file through a scheduled job.
The version is close/latest to the version I'm using in my project. https://world.episerver.com/documentation/class-libraries/rest-apis/service-api/
And the commerce version is
I've got a scheduled job that reads an XML through asset pane and imports the entries / catalog from that file. This file is using Service APIs to import an entry and it's associations with following code base, in following order -
import the entries -
Import the prices -
Node entry relations -
Catalog Association -
We've been getting intermittent response from the prod server where the each of above APIs would fail at some point with the response "User is not authorized for this request". Though the user which this API client is using exists with all the required credentials and has enough permissions for functions to read/write the catalog.
The API is making connection to the Service API through OAuth2Client. Here is the complete file -
The issue is only occuring at production which is on-premise. Does it have to do anything with the permissions those need to be allowed? I've no clue why this is failing or even where to look for if this is a permission issue.
Thanks for your help.