Hi @chrislambertus, may I ask what version of the service extension project was it based on? Reason being since Feb 26 there’s an introduction of the “Dynamic Base Path”: Getting started with the service extension | AccelByte Documentation. If you updated to the latest version, then according to the documentation, you need to create a new Extend app to fix the issue.
I’m not sure what version it was, but it looks like I used a sample that was available in early-to-mid January. I’ve been grabbing the latest sample and pulling in differences from time to time (Makefile, etc.), but you think I need to start from scratch?
I see. We can see that the Extend app on the Admin Portal was indeed created prior to Feb 26. Could you recreate with a new Extend app in the Admin Portal, upload the image, and try again to open your service’s API docs? If this is working, then you can continue to generate your SDK and try calling from your game again.
I’ve created a new Service Extension and set up my app to use the new values (ID/secret, repo URL, etc.). I uploaded it and generated the SDK, but I get the same error.
Interestingly, I can’t get to apidocs for either the old app or the new app (NewThing). I append /apidocs to the Service URL or click the API Documentation link on the app page, and get a 404 on both.
Yes, I could run the localhost API docs – that was my first test.
However, I just checked and it seems like my local .env changes to the new client ID didn’t stick. I’m not sure what happened there, I definitely remember changing it. It could have been using the old IAM client instead of the automatically created new one. I made sure to switch to the new one and now I get “invalid client” errors.
I’ve made sure the ID and secret match now between the app configuration on AB, the new IAM client, and the .env file in the service extension. I’ve restarted the app as well. I ran make build and docker compose up --build, and while I can access apidocs locally it’s getting an invalid client error when I try to execute a command. The same error happens when I run the extend auth step before uploading.
I’m doing all this with auth set to false just to remove that complication for now.
The issue is confirmed resolved on another thread.
Thank you very much for the customer working closely with us to work towards the resolution, and help us to improve our developer’s flow.
Here is a full summary:
Initial issue was due to an integration issue with the customer’s copy of the service extension sample from the latest (as latest had some major updates to do with the REST gateway code).
Further complication**: there was also a recent requirement introduced after Feb 26 that for the latest service Extension app created will require the latest source code to be integrated, and vice versa, which complicates the big picture.
Ultimately after back and forth, we’ve worked with the customer to correctly resolve and merged the customer’s sample code with the latest.
Action item: will find out the best practice for hosting our service extension samples as right now we’re treating it more than a sample but more like a template which will require more attention due to the fact that customers will be expected to further pull in updates going forward. Guideline and Docs Portal will be revisited.
There was also a confusion with the environment credential on the Admin Portal between the manually created one under Authorizations->IAM Clients and the auto-generated one from Extend app creations - the confusion point was that the auto-created one from the Extend app creation does not have the secret revealed at all by designed to avoid the same credential being reused in another Extend app (to promote 1 app: 1 IAM Client).
We have also clarified the use of the .env file is solely for local usage (during local testing and image push) and not coupled with the deployed environment variables under the Admin Portal as that could be confusing as well
Action: we will revisit the Docs Portal to help clarify.
There was also a confusion for the usage of schemes “HTTP” vs “HTTPS” within the apidocs page. “HTTP” is only for local testing while AB hosted environment will require “HTTPS”, or otherwise will yield the following error:
Failed to fetch. Possible Reasons:
CORS
Network Failure
URL scheme must be “http” or “https” for CORS request.
Action: we will look into the possibility of having this flow improved, and will revisit the Docs Portal to emphasize this
At the AB hosted environment, env var PLUGIN_GRPC_SERVER_AUTH_ENABLED is by default true if not specified. When customers want to simplify testing they will need to set this environment variable to false explicitly on Admin Portal. *** Note that as a security best practice, after testing is done please remember to re-enable PLUGIN_GRPC_SERVER_AUTH_ENABLED
Actual applying of environment variable changes does require an app redeploy via clicking on the “Restart and Apply” button. It is visible on the Admin Portal but we can certainly improve the UI aspect of it. Action is being carried out internally to assess and improve its usability side of things.
Lastly, Unity code generator had a bug in it related to the recent change for the BaseUrl being used. A hot fix (Release v0.0.15-alpha · AccelByte/extend-codegen-cli · GitHub) was quickly tested and put in and made available to the customer. Action will be taken to better catch these types of end to end issues.Customer has now confirmed everything works from top to bottom.