-
Notifications
You must be signed in to change notification settings - Fork 5
Documentation not up-to-date #91
Comments
I'm trying to achieve the same as @giuliocarot0, and had the exact same results. I tried on both a Mac and a Debian machine with the same outcome. Here's the problems I've seen so far:
So at this point, I don't really have anything to test with, as this is the go-to samples to test out building a provider for CAPIF. |
Hello, I apologize for the delay in my response. 1. the endpoint /gettoken seems replaced by /getauth (by looking at the nginx service configuration), or the role exposer replaced by provider. / The Curl scripts doesn't seem to work The Curl tests have not been updated to reflect the latest changes. As you rightly pointed out, the current endpoint should be /getauth rather than /gettoken, besides having to use 'provider' instead of 'exposer' 2. The written test case and the Curl scripts doesn't follow the same flows (Curl scripts call /sign-csr and written test case states calling /api-provider-management/v1/registrations) This situation involves preconditions. It's essential to initiate the process with /register and /getauth in order to obtain a valid token for interacting with CAPIF. Subsequently, the certificate must be signed through /sign-csr using the token acquired earlier. This leads to the eventual onboarding of CAPIF. 3. The Postman templates is way out of date (I know the documentation states this is only works for CAPIF 1.0), but it would be great to actually test it though Postman. While the Postman template initially served as a useful tool for developers, it no longer maintains current relevance. CAPIF adheres to standard specifications, thereby enabling anyone to construct collections within Postman. 4. Can't run the Robots test, because when the it tries to build the Docker image for the robot The repository has been updated to incorporate the required Robot image essential for successful test execution. 5. Running each service individually doesn't work as specified (e.g. like this) because services like Redis have a hardcoded container hostname to 'redis', so it won't start unless it was started thought the complete docker-compose setup You've aptly identified the situation. With services reliant on the Redis service, it's presently impossible to launch CAPIF services individually. We recommend leveraging the run.sh script within the services directory to initiate CAPIF, encompassing all necessary components. Moreover, we are diligently working on an upcoming version that will introduce a plethora of substantial enhancements. These alterations have been designed to uphold the existing structure while significantly enhancing the overall user experience when engaging with CAPIF. |
Hi! Thanks in advance! The modified bash script:
|
Update: In the node.js HTTP server I created, if I send the signed certificate with, with adding to it the encoding information, then there is an error (Certificate not authorized.), but without it, there is no information sent back. |
The output of the curl bash file:
|
Hello all! Hope to see you there! |
Dear all, I am testing you framework and trying to implement an API Provider.
I tried to test the CAPIF Core Services using both the curl scripts and the postman templates, however in both cases I think the doc is incoherent with the endpoints exposed by the Core.
For example, the endpoint /gettoken seems replaced by /getauth (by looking at the nginx service configuration), or the role exposer replaced by provider.
Is there something I am missing? or the docs are not updated? if not, are you planning to update them?
The text was updated successfully, but these errors were encountered: