search

secvisogram / csaf-validator-service

csaf-validator-service is a REST-based service that can be used to check whether a given CSAF 2.0 document is valid.
MIT License
0 stars 6 forks source link

csaf-validator-service missing documentation for test setup with secvisogram #57

Closed ljaenicke closed 10 months ago

ljaenicke commented 1 year ago

When performing a test setup, using the "Validate" service fails as the first call from secvisogram is OPTIONS for /api/v1/validate. The out-of-the-box csaf-validator-service however does not support OPTIONS and returns a 404. {"message":"Route OPTIONS:/api/v1/validate not found","error":"Not Found","statusCode":404} The server should be extended respectively or a documentation on how to deal with the situation added.

tschmidtb51 commented 1 year ago

Shouldn't that be handled by the reverse proxy? (I might be completely wrong here) :thinking: Can you please describe a little bit more what the setup would look like? (How do you run Secvisogram (Dev/Production, Server/Standalone mode, behind a proxy...) and how did you configure it to work with the validation service?

ljaenicke commented 1 year ago

I am currently at the first stage: get it started with all modules in a test environment (currently local virtual machine on my laptop with its own network interface assigned). I am using the setup "out of the box" with the validation service configured to operate on localhost:8081 to be reached directly. Once this is up and running, we can determine what we need to do to turn this into a production setup (inside the enterprise network, reachable via proxy, using enterprise user management, having backup for the configuration and the advisory database...). The full packages looks promising. I have proposed a CORS support pull request in the csaf-validator-service repo. If this a good idea or not, I don't know, at least it allowed me to get a fully operational TEST installation. Having this said, I already see the first issue arising: In the mustache Template.html external styles are hardcoded and in a productive environment "weasyprint" will have a hard time loading these styles (behind a firewall, the proxy could be reached but would need authentication, etc.). The styles could of course be inlined (works) but then the automatic tests fail because the text is hard coded there... Should I open an issue for this topic?

tschmidtb51 commented 1 year ago

The styles could of course be inlined (works) but then the automatic tests fail because the text is hard coded there... Should I open an issue for this topic?

Please do so in the appropriate repo.

tschmidtb51 commented 1 year ago

@ljaenicke Is that issue resolved for you?

tschmidtb51 commented 11 months ago

@ljaenicke Does the current version resolve the issue for you?

ljaenicke commented 10 months ago

Resolved.