View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0008371CTT UA Test CaseApi Changepublic2022-09-29 15:092024-02-01 16:55
ReporterMartin Herberg Assigned ToAlexander Allmendinger  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionfixed 
Fixed in Version1.03.09.503 
Summary0008371: Discovery Find Servers Self: contradictory test descriptions
Description

Some of the test descriptions seam not to match the specification or contradict each other.

002: "Provide an EndpointDescriptionUrl with a hostname not known to the server." -> return server array with default entry
006: "Specify an EndpointUrl with a large payload, e.g. 4096kb of text." -> return an empty server array
007: "Specify an endpointUrl with a payload to try to execute code, e.g. http://127.0.0.1/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+\" -> return an empty server array
008: "Provide an invalid EndpointUrl (string, but syntactically not a URL)." -> return server array with default entry.

It is not clear, when an empty array must be returned instead of a server array with a default entry.

The specification (5.4.2.2 Table 3, OPC 10000-4, Release 1.04) of endpointURL in Find Servers Request Parameters is:
"The network address that the Client used to access the DiscoveryEndpoint.
The Server uses this information for diagnostics and to determine what URLs to return in the response.
The Server should return a suitable default URL if it does not recognize the HostName in the URL."

With this definition I would assume, that in all 4 cases a default array is returned. (Or 006 returns a service fault because of invalid data (more than 4096 Bytes as URL)).

Additional Information

Received response via E-Mail from Alexander Allmendinger:
"Following the specification: When it is a valid URL and the server knows the hostname it should be used to mask the EndpointUrls, when the URL is valid but the server does not know it, it returns a default URL and if it is not a valid URL at all, an empty list is returned."
But this seems not to match the part of the specification I've found.

TagsNo tags attached.
Files Affected

Activities

Martin Herberg

2023-03-01 16:14

reporter   ~0018824

Hello,

do you have any new information about this topic?

Thank you very much.

Martin Herberg

2024-01-23 14:56

reporter   ~0020692

Hello,

one year later again: do you have any new information about this topic?

Thank you very much.

Alexander Allmendinger

2024-01-25 13:44

developer   ~0020704

After looking at the current version of the specification I think the expected results of the test cases need to be updated ...

Looking at the specification I only see two cases discussed:

  1. Server knows the endpointUrl --> Returns its Endpoints with those endpointUrls
  2. Server doesn't know the endpointUrl --> Returns default endpointUrls

I don't see an empty list need to be returned no matter which endpointUrl is specified. Even for syntactically invalid endpoint urls case 2 should be applied.

The only reason to get an empty list in the response is, when the client specified a list of serverUris where none is available in the server.

This needs a CMP and potentially a UA WG discussion to change the expectation.

Alexander Allmendinger

2024-01-26 16:46

developer   ~0020719

CMP Discussion: Update test cases 006 and 007 with:

  • it is expected to receive the default list servers
  • if the server considers this an attack, it is also acceptable that the server returns an empty list
  • if the server considers this an attack, it is also acceptable to close the socket and return an Error Message

Martin Herberg

2024-01-29 09:12

reporter   ~0020723

Hello,

thank you very much. From my side, this ticket can be closed. I think the test descriptions must be updated to completely close this issue.

Alexander Allmendinger

2024-02-01 13:11

developer   ~0020743

Test cases have been updated as discussed.

Paul Hunkar

2024-02-01 16:55

administrator   ~0020751

reviewed in call - agreed to update and closed issue

Issue History

Date Modified Username Field Change
2022-09-29 15:09 Martin Herberg New Issue
2022-11-09 13:54 Paul Hunkar Project UA Server - Certification tests => CTT UA Binary
2022-11-09 13:54 Paul Hunkar Category Spec => Api Change
2022-11-18 16:42 Paul Hunkar Project CTT UA Binary => CTT UA Test Case
2022-11-18 16:45 Paul Hunkar Assigned To => Alexander Allmendinger
2022-11-18 16:45 Paul Hunkar Status new => assigned
2023-03-01 16:14 Martin Herberg Note Added: 0018824
2024-01-23 14:56 Martin Herberg Note Added: 0020692
2024-01-25 13:44 Alexander Allmendinger Note Added: 0020704
2024-01-26 16:46 Alexander Allmendinger Note Added: 0020719
2024-01-29 09:12 Martin Herberg Note Added: 0020723
2024-02-01 13:11 Alexander Allmendinger Status assigned => resolved
2024-02-01 13:11 Alexander Allmendinger Resolution open => fixed
2024-02-01 13:11 Alexander Allmendinger Note Added: 0020743
2024-02-01 16:55 Paul Hunkar Status resolved => closed
2024-02-01 16:55 Paul Hunkar Fixed in Version => 1.03.09.503
2024-02-01 16:55 Paul Hunkar Note Added: 0020751