8 replies
3 replies
Just for your information, we’ve just released new plgd hub version v2.2.0 . Mock OAuth Server which is built in in the bundle now works with the CTT tool, that means, you don’t need any external OAuth Server. You can execute all the tests just by running the bundle.
Hello Wouter. Jozef found the issue already. As soon as he is online, he will upstream the fix. I don’t know where the problem was. Let’s see.
What do you mean issue with plgd? Where do you experience something failing, where plgd hub is included? Do you mean plgd hub tests?
@kwlodarczyk no, we don’t have this issue.
Just for your information, we’ve just released new plgd hub version v2.2.0 . Mock OAuth Server which is built in in the bundle now works with the CTT tool, that means, you don’t need any external OAuth Server. You can execute all the tests just by running the bundle.
@ondrejtomcik
Sorry for delayed answer. Yes, the updated plgd bundle works well. To account for the changes you mentioned Comarch needed to revise handling of account linking, retrieving token for device etc. which for previously used external auth server already took significant amount of time to figure out and automate. Automated tests of Target Cloud are soon to be finished. After additional adjustments they work well with the current plgd bundle, with the mocked oauth server as well as with the auth0.
Origin Cloud conformance testing is in progress.
Please let me know once you have this ready so Comarch can begin work on automating Origin Cloud tests.
1 reply
Hi @SiMet , @kwlodarczyk , I'm working on Origin Cloud test cases and I'm currently stuck on 6.3.1. I keep getting an SSL connection error.
13:28:29 DEBUG Starting verification with ID:"CT6.3.1_Check_3"...
13:28:29 DEBUG Checking response(s) to notification(s) for event devices_registered for subscription 3ed8877f-1751-4e1b-a3f2-3337a0fe3015
13:28:29 DEBUG Response to notification request ID=46461973: <request failed>
13:28:29 ERROR CT6.3.1_Check_3: Notification request ID=46461973 for event devices_registered for subscription 3ed8877f-1751-4e1b-a3f2-3337a0fe3015 failed: The underlying connection was closed: Could not establish t...
13:28:29 DEBUG continued: ...rust relationship for the SSL/TLS secure channel.
13:28:29 DEBUG Verification with ID:"CT6.3.1_Check_3" ended with result: FAILED
I think it's trying to send message to eventsUrl (in my case https://192.168.1.44/c2c/connector/api/v1/events
), but it cannot establish connection. This is the relevant part of my PICS configuration file:
"cloudClientTrustAnchorCertificate": "...",
"redirectUri": "https://192.168.1.44/c2c/connector/api/v1/oauthCallback",
"bulkSubscribe": true,
"asynchronousOperation": false,
"supportedSubscriptionEventTypes": ["devices_online", "devices_offline", "devices_registered", "devices_unregistered", "resources_published", "resources_unpublished", "resource_contentchanged"],I've changed the cloudClientTrustAnchorCertificate to rootCA certificate of my running plgd-dev bundle, but it doesn't seem to work. Any idea what I might be doing wrong? Thanks.
Hi @Danielius1922,
After quickly looking at the code I suspect that the notification sender inside the CTT's Target Cloud simulator may be lacking a piece of code that makes use of the "cloudClientTrustAnchorCertificate" PICS value. However I'm not 100% sure yet. I'll try to look into this and let you know.
If my suspicion turns true, then Comarch will need to fix that. As a temporary workaround you could try to install the plgd root cert as a trusted root CA in windows before running the CTT.
@Danielius1922, @ondrejtomcik
Thanks for checking. I've confirmed today that the the CTT indeed does not configure trusted CA for requests containing notifications. This needs to be corrected on the CTT side. The fix is not very complex, however it would require to prepare an unofficial dedicated release to deliver it. Is it sufficient for you to finish your job using the mentioned workaround or is it necessary to release the fix to you?
2 replies
@ondrejtomcik
Do you mean that different configuration is needed to pass individual test cases? I think this could be simplified at least partially just by using one PICS for multiple tests. If you can su
Please note that CTT test cases only implement what is written in the CTR. The fact that each test case requires a slightly different setup is a dictated by conditions specified in the CTR. If we are talking about changing PICS values for specific test cases then I agree that it should not be needed. The values that you set in the tutorial exclusively for specific tests should rather be defined once as they specify the behavior of the IUT. In my understanding an IUT that is under certification should stick to one behavior and apply only to those test cases which verify that behavior, other tests should be NA. If you say that asynchronousOperation is supported, then you should only run CT6.3.4 and CT6.3.1-3 are NA; and conversely, if it is not supported, you run CT6.3.1-3 and CT6.3.4 is NA. Which test is applicable to which behavior is dictated by the CTR. We cannot change the implementation unless OCF changes the CTR. I understand that plgd supports both and of course there is value in testing both, however the eventing test cases are not designed to be executed all in one run.
I don't see any other PICS configuration that would need to be set exclusive:
- cloudClientTrustAnchorCertificate can be set once for all test cases; it is used only to allow verification of server certificate when CTT Target Cloud simulator sends a notification to Origin Cloud; in other test the value is not used
- bulkSubscribe can be set once; tests other than CT6.3.x just ignore that option
- redirectUri - this value is simply displayed to the Test Operator in each prompt to do Account Linking
To sum up, the tutorial can be simplified to provide all the PICS values once, with "asynchronousOperation": false and if you want to test also the asynchronous behavior, then you could provide second PICS with "asynchronousOperation": true. For each of the two you can run all the test cases:
- those which are not applicable will be NA
- for some tests the CTR defines separate test flow
- other will run exactly the same flow as for the other behavior
Please let me know if you have specific suggestions on what else can be done to make the setup less complex.