Error with registering AAS

[sunshineRunner22]

I'm trying to register my AAS in FA³ST Service to FA³ST Registry. FA³ST Registry is running here: https://localhost:8090/api/v3.0/shell-descriptors

The core part in Config.json looks like this: { "core" : { "aasRegistries": [ "https://localhost:8090" ], "submodelRegistries": [ "https://localhost:8090" ] } }

I'm getting the followig error message: [WARN] Registering submodel descriptor in registry failed (id: https://example.org/submodel/2, registry: https://localhost:8090, reason: bad return code 400) (de.fraunhofer.iosb.ilt.faaast.service.registry.RegistrySynchronization) [WARN] Registering submodel descriptor in registry failed (id: https://example.org/submodel/1, registry: https://localhost:8090, reason: bad return code 400) (de.fraunhofer.iosb.ilt.faaast.service.registry.RegistrySynchronization) [WARN] Registering AAS descriptor in registry failed (id: https://example.com/ids/sm/3122_5150_2042_4130, registry: https://localhost:8090, reason: bad return code 400) (de.fraunhofer.iosb.ilt.faaast.service.registry.RegistrySynchronization)

As a second test I tried to connect to BaSyx Web UI. Is this comaptible with FA³ST? (https://wiki.basyx.org/en/latest/content/user_documentation/basyx_components/web_ui/index.html) When I try to register my AAS in FA³ST Service to the BaSyx Registry, I'm also getting error messages:

"core" : { "aasRegistries": [ "http://localhost:8082" ], "submodelRegistries": [ "http://localhost:8083" ] } },

[WARN] Registering submodel descriptor in registry failed (id: https://example.org/submodel/2, registry: http://localhost:8083, reason: bad return code 500) (de.fraunhofer.iosb.ilt.faaast.service.registry.RegistrySynchronization) [WARN] Registering AAS descriptor in registry failed (id: https://example.com/ids/sm/3122_5150_2042_4130, registry: http://localhost:8082, reason: bad return code 500) (de.fraunhofer.iosb.ilt.faaast.service.registry.RegistrySynchronization) [WARN] Registering submodel descriptor in registry failed (id: https://example.org/submodel/1, registry: http://localhost:8083, reason: bad return code 500) (de.fraunhofer.iosb.ilt.faaast.service.registry.RegistrySynchronization)

The BaSyx adresses look like this:

I'm I doing something wrong or missing something in the config? Thank you.

[fvolz]

Hi, regarding the registration we pushed a quick fix that should solve the issue. You can find the newest snapshot here: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=de.fraunhofer.iosb.ilt.faaast.service&a=starter&v=1.2.0-SNAPSHOT Let me know if that fixed the issue.

Regarding the Basyx Web UI, I think it is not compatible out-of-the-box since FA³ST is by default SSL-encrypted with self-signed certificates.

[sunshineRunner22]

The fix works (with and withput SSL enabled), no more errors. Thank you!

However, when I call http://localhost:8090/shell-descriptors, I get the following message (same for /submodel-descriptors): Should't be a result returned there?

Unfortunaltely, BaSyx Web UI really doesn't work, like you said. However, I don't understand that. I turned off SSL and thought I could just provide the FA³ST AAS and Submodel Registry URL to the Web UI (see screenshot in my last post), but it doesn't connect. I probably thought too simply.

[mjacoby]

I guess there might be some kind of misunderstanding here. FA³ST Service implements an AAS/Submodel repository; it does not include a registry. If you want to also run a registry using FA³ST, please use https://github.com/FraunhoferIOSB/FAAAST-Registry which you have to run as a separate tool.

As I am not familiar with BaSyx WebUI I cannot provide any support regarding this. However, this might be related to the previous problem and the UI might be crashing because there is no registry running. In theory the UI should work with FA³ST as long as it is compliant to the AAS specification.

[sunshineRunner22]

I know that I need a registry, I already have FA³ST Service and Registry running. But I just noticed that I missed /api/v3.0 in the url... With http://localhost:8090/api/v3.0/shell-descriptors I get a result. Can't get it working with BaSyx AAS Web UI though, doesn't seem to be compatible. But I understand that you can't provide any support regarding this. Thanks!

[aaronzi]

@sunshineRunner22, I will have a look at the compatibility to the BaSyx AAS Web UI. Do you have a setup that you can share as zip so that I don't have to create it on my own?

[sunshineRunner22]

@aaronzi Sure! You can download the jar-files for Service and Registry here:

• Service: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=de.fraunhofer.iosb.ilt.faaast.service&a=starter&v=1.2.0-SNAPSHOT
• Registry: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=de.fraunhofer.iosb.ilt.faaast.registry&a=service&v=1.1.0-SNAPSHOT

An aasx-file can be found here: https://github.com/FraunhoferIOSB/FAAAST-Service/tree/main/docs/source/aas-examples The file has to be renamed to model.aasx!

Put the two jar-files, the model.aasx and these config-files into the same folder: config.zip

Then first run the jar of the Registry and afterwards the jar of the Service.

Afterwards the following urls should return a result: http://localhost:8090/api/v3.0/shell-descriptors http://localhost:8090/api/v3.0/submodel-descriptors

Thanks for the support!

[aaronzi]

Here are my findings:

Both the registry and the service were missing the necessary CORS configuration. For the registry, the settings have to look like this:

###### RDBS via JPA #####
spring.jpa.orm=orm.xml
#spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
spring.jpa.hibernate.ddl-auto=update
spring.jpa.open-in-view=true
server.port=8090
server.ssl.enabled=false
cors.enabled=true
cors.allowedMethods=GET, POST, PUT, DELETE, OPTIONS, HEAD, PATCH
cors.allowedOrigins=*
cors.allowedHeaders=*
#########################

For the service, I tried this:

{
    "core" : {
        "aasRegistries": [
            "http://localhost:8090"
        ],
        "submodelRegistries": [
            "http://localhost:8090"
        ]   
    },
    "endpoints": [
        {
            "@class": "de.fraunhofer.iosb.ilt.faaast.service.endpoint.http.HttpEndpoint",
            "port": 8091,
            "sniEnabled": false,
            "sslEnabled": false,
            "corsEnabled": true
        }
    ]
}

I was already able to connect the AAS and Submodel Registry (shell-descriptors, submodel-descriptors) with the BaSyx AAS Web UI like this.

However, the service isn't working because of the lack of configuration options regarding the CORS settings. It is missing the allowedOrigins and allowedMethods options. I can confirm that when using Postman to check the response headers. The registry has them but not the service.

@mjacoby and @fvolz would you be able to add those config options?

[mjacoby]

Thank you for the detailed analysis and feedback. You are correct that FA³ST Service does currently not allow configuring the headers Access-Control-Allow-Origin and Access-Control-Allow-Methods. However, they are still being set by the server

• Access-Control-Allow-Origin is always set to *
• Access-Control-Allow-Methods is set to the actual allowed methods of the requested URL + OPTIONS

It is to note that Access-Control-Allow-Methods is only set for pre-flight CORS requests (i.e. for OPTIONS calls).

You can find the related code here https://github.com/FraunhoferIOSB/FAAAST-Service/blob/4e06fce376955c26c7516ded4d49d91690fcbd94/endpoint/http/src/main/java/de/fraunhofer/iosb/ilt/faaast/service/endpoint/http/RequestHandler.java#L165C2-L216C1

I am not 100% sure if this behavior is correct but so far we did manage to get things running in all use cases even when CORS is required. Nevertheless, we will put a task in our backlog (with low priority) to revisit and investigate if CORS if implemented correctly in all cases. We probably will also exposed allowedOrigins to be configured because always using * seems like a security issue.

@aaronzi If you can point out what exactly you think is incorrect behavior and/or which calls the BaSyx Web UI is making that fail this would be highly appreciated and probably speed things up.

P.S.: The reason the configuration is different for FA³ST Service and FA³ST Registry is that they are using different technologies.

[aaronzi]

Thank you for the detailed response @mjacoby.

The problem here is that you are returning Access-Control-Allow-Credentials: true which is not allowed together with Access-Control-Allow-Origin: * for security reasons. So either the configuration of the origin needs to be available or the Access-Control-Allow-Credentials header needs to be set to false. This is true for all non-OPTIONS requests. The OPTIONS preflight is successful.

Hope this helps for fixing the problem.

[mjacoby]

I have done a complete rework of the CORS handling in FA³ST Service and you can now configure all CORS-related properties via the configuration. If you could test again with the latest version of FA³ST Service to see if everything now is working as expected would be appreciated. You can use the latest SNAPSHOT as linked on the readme (https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=de.fraunhofer.iosb.ilt.faaast.service&a=starter&v=1.2.0-SNAPSHOT) or just the latest docker image. Details about the configuration can be found here https://faaast-service.readthedocs.io/en/latest/interfaces/endpoint.html#configuration

[aaronzi]

Thanks a lot @mjacoby. Now there seems to be no CORS related issue anymore. I noticed another small incompatibility that needs to be addressed. The shell-descriptors and submodel-descriptors that are being created display the endpoint to the respective repository first and not the endpoint for the AAS/Submodel that is referenced by the descriptor (see example):

"endpoints": [
        {
          "protocolInformation": {
            "endpointProtocol": "HTTP",
            "endpointProtocolVersion": [
              "1.1"
            ],
            "href": "http://192.168.178.49:8091/api/v3.0/shells",
            "securityAttributes": [
              {
                "key": "",
                "type": "NONE",
                "value": ""
              }
            ],
            "subprotocol": null,
            "subprotocolBody": null,
            "subprotocolBodyEncoding": null
          },
          "interface": "AAS-REPOSITORY-3.0"
        },
        {
          "protocolInformation": {
            "endpointProtocol": "HTTP",
            "endpointProtocolVersion": [
              "1.1"
            ],
            "href": "http://192.168.178.49:8091/api/v3.0/shells/aHR0cHM6Ly9leGFtcGxlLmNvbS9pZHMvQXNzZXRBZG1pbmlzdHJhdGlvblNoZWxsLzg3MTNfMzMyMl84MDU1XzI5NDA=",
            "securityAttributes": [
              {
                "key": "",
                "type": "NONE",
                "value": ""
              }
            ],
            "subprotocol": null,
            "subprotocolBody": null,
            "subprotocolBodyEncoding": null
          },
          "interface": "AAS-3.0"
        }
      ],

This could be solved in two ways. Either we adapt the UI to not statically look into the first endpoint and take whatever is defined there in the href or you guys change the order of the endpoints.

Or maybe both would be a good approach. I think the added flexibility in the UI would be a good thing but also in the FAAAST service a change to display the endpoint to the AAS/Submodel first would make sense to me.

What do you think?

Just to verify that it would work I changed the logic of the UI to take the second endpoint and that seems to be working without any issues:

[mjacoby]

Thanks for the quick response @aaronzi ! I do not see any need to change the order of the endpoint information from the registry as this is not part of the specification. Both entries are valid and it is up to the application to decide which one it likes/know how to use. Therefore, the correct approach would be to update your UI to take care of this issue by looking at the interface property and select the one you can work with.

As everything seems to work when you select the proper endpoint I would close this issue. Also, we have gone quite off from the original issue but I think it still was a fruitful discussion to have. Thanks @aaronzi and @sunshineRunner22 for your input and efforts!

[aaronzi]

You are right. Just checked the specification. I did not know this existed:

Thank you for the great discussion and the fast response/fix :)