When using the any method of the client generated by 2.3.0, as recommended #6777, that requires authentication, eg. oauth/sso it fails with this error:
Exception: [403] Client error: `POST https://esi.tech.ccp.is/latest/characters/93588930/mail/?datasource=tranquility` resulted in a `403 Forbidden` response:
{"error": "Missing or invalid token.", "sso_status": 400}
and it doesn't matter whether I directly give the access token as a parameter to the method or set it via
Swagger\Client\Configuration::getDefaultConfiguration()->setAccessToken('YOUR_ACCESS_TOKEN');, both lead to the same error
Over the last two weeks i have tried multiple versions of the 2.3.0 SNAPSHOT, and as far as I can tell 3.0.0 SNAPSHOT has the same problem
Is it correct to say that the endpoint has the proper security definition applied? e.g. https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/test/resources/2_0/petstore.yaml#L280
In the definition file that was used to generate the client it says eg.:
security: [
{
evesso: [
"esi-mail.send_mail.v1"
]
}
],
so I assume that means yes
@jbs1 I tried request to real API which requires authentication with client generated by lastest master, and received expected response with no error.
Would you please show me a sample (API definition/codes using generated client) which reproduce the problem?
@jbs1 Please try passing Configuration into api constructor like following 馃挕
$config = Swagger\Client\Configuration::getDefaultConfiguration()->setAccessToken('YOUR_ACCESS_TOKEN');
$api_instance = new Swagger\Client\Api\PetApi(
null, // use default client (as `GuzzleHttp\Client`)
$config // use configuration which includes your token
);
I noticed that there is a matter in generated docs which should be fix.
// Configure OAuth2 access token for authorization: petstore_auth
SwaggerClientConfiguration::getDefaultConfiguration()->setAccessToken('YOUR_ACCESS_TOKEN');$api_instance = new SwaggerClientApiPetApi(new HttpAdapterGuzzle6Client());
If api requires authorization, in addition to set YOUR_ACCESS_TOKEN, we need pass the configuration which includes token into api constructor.
But generated doc does not show that 馃挦 .
@ackintosh
I changed the code according to your suggestion but it gives the same error:
<?php
require_once('header.php');
header('Content-Type: application/json;charset=utf-8');
$api_corp = new Swagger\Client\Api\CorporationApi(null,$config);
try {
$corpmem = $api_corp->getCorporationsCorporationIdMembers(corpid(charid()),$datasource);
echo json_encode($corpmem);
} catch (Exception $e) {
echo 'Exception: ', $e->getMessage(), PHP_EOL;
}
?>
The $config is set in the the header.php via
$config = Swagger\Client\Configuration::getDefaultConfiguration()->setAccessToken(unserialize($_SESSION['accesstoken-obj'])->getToken());
The api definintion here is used: https://esi.tech.ccp.is/latest/swagger.json
and the client is generated with the latest snapeshot build for 2.3.0 (swagger-codegen-cli-2.3.0-20171030.060918-211.jar)
... 馃
@jbs1 I'll try to take another look tomorrow.
Thanks @ackintosh for troubleshooting this issue.
@jbs1 did you find the following lines in the endpoint that requires OAuth authentication in the *Api.php files?
// this endpoint requires OAuth (access token)
if ($this->config->getAccessToken() !== null) {
$headers['Authorization'] = 'Bearer ' . $this->config->getAccessToken();
}
{"error": "Missing or invalid token.", "sso_status": 400}
Also the error message mentions about invalid token so there's a possibility the token is invalid.
@wing328 I checked and the lines you mention are in the code for the endpoints i use.
And I doubt the access token is wrong, because I tested the same tokens with a restclient i have installed and there it worked flawlessly.
@jbs1 Could you debug the $headers? If $headers contains Authorization key and token which you passed, it means that generated codes works fine.
@jbs1 what about using the stable version 2.2.3 to generate the PHP client and give it a try? This will help us isolate the problem.
(PHP client in 2.3.0 has been refactored)
@wing328 I have been using 2.3.0 exactly because the php client has been refactored as you suggested in #6777 in this comment.
@ackintosh I will get to that as soon as I find the time
@jbs1 Yes, we've been asking users to try 2.3.0 as the PHP client has been refactored.
To try to identify the issue, I simply suggest giving 2.2.3 a try as the setting OAuth2 access token should still work with PHP client generated by v2.2.3 stable release.
after following the improved doc from the merged, it seems the access token is recognized properly now.
There messed up when setting the $config variable.
the problem #6777 still persists even in 2.3.0
Reopened #6777