Environment:
- Windows Server 2012 R2
- JRE 1.8.0_101
- IBM WAS Liberty Core 8.5.5.5
- IBM MFP 8.1
- Apache Web server
We have set up the UAT with the above environment. We have deployed our application on the server, have deployed adapter for user authentication and a resource adapter to fetch the data.
When we invoke an adapter procedure without security (unprotected) the app is fetching the data. But when we try to invoke an adapter procedure with default scope or with a custom scope Instead of triggering the challenge handler, we are getting failure response with error status ‘201’ and error message ‘Created’.
Another observation is that, when the WLAuthorizationManager.ObtainAccessToken
is invoked with default scope or with push.mobileclient
, it is giving the same failure response with error status ‘201’ and error message ‘Created’. The same application works fine in the development environment.
When I try to obtain a token from postman using https://domain:port/mfp/api/az/v1/token
and pass the scope, grant_type and the necessary authorization header, it is providing the valid response with token. But from the app when we try by obtain token it is given failure response.
Failure response
{"status":201,"statusText":"Created","responseText":"","responseHeaders":{"connection":"Keep-Alive","content-language":"en-US","content-length":"0","date":"Fri, 17 May 2019 05:42:45 GMT","keep-alive":"timeout=5, max=100","location":"/mfp/api/registration/clients/1e746550-e804-4ee7-88ba-b99896qqqqpwo","server":"Apache/2.4.39 (Win64) OpenSSL/1.1.1b","via":"1.1 ","x-powered-by":"Servlet/3.0"},"errorMsg":"Created","errorCode":"201"}
2
Answers
201 is not a response code that is expected from the /token endpoint. This is very likely coming from an intermediate element in your topology. You’ve mentioned about the Apache Web Server as part of the configuration – is this sending the 201 ?
Moreover, the actual response from the server shows
"server":"Apache/2.4.39 (Win64) OpenSSL/1.1.1b"
So, here is what you can do
a. Try bypassing the web server and see if resolves the issue – in all likeliness, it should.
b. Validate the configuration settings of the Apache Web server to see why the 201 is being returned.
Late to the party, but for anyone that is still running into this error:
Install the following interim fix: 8.0.0.0-MFPF-IF202006151151
This solved the error for me. Seems to be a bug in MobileFirst, took me ages to find.