Brabandse Delta server info

[hylkevds]

The server of Brabandse Delta is available under the url: https://sta.wbd-rd.nl/FROST-Server/v1.1
The data model and extensions available are:

• SensorThings version 1.1
  • data model image
  • The core standard OGC 18-088.
• SensorThings Tasking
  • data model image
  • The Tasking extension defined in OGC 17-079
• OpenCitySense
  • data model image
  • The custom extension for managing sensors. Detailed description here.
• Projects
  • data model image
  • A custom extension that allows assigning entities to Projects. Also allows fine-grained access control, though that is currently not used yet.

The easiest way to keep things separated between the different groups is if each groups makes their own Project entity, and links their Things, Locations, Sensors and Features to their Project. If need be, we can then add user accounts that are linked to these projects, and restrict these account to only be able to modify data for those projects.

[justinschembri]

Thank you Hylke,

I've successfully added a number of Things to the server and Observations are being pushed.

I didn't see this post before doing so, so I will have to patch my created entities to connect them to a Project.

[justinschembri]

@hylkevds

Would it be possible to assign patching (maybe even deleting) rights to the write user we're using right now?

[hylkevds]

Indeed, PATCH does not work. Probably a configuration thing in nginx, I'll look into it.

[justinschembri]

Hey Hylke,

I get a 403, here's my request:

url: https://sta.wbd-rd.nl/FROST-Server/v1.1/Things(101)/Locations
payload: {location: {type: "Point", coordinates: [4.37034, 52.00482]}}

(inverted long/lat)

[hylkevds]

Can you give PUT a try for now, until we fix it? Not as convenient, since you have to supply all fields, instead of just what you want to change...

[justinschembri]

That works :)

[hylkevds]

Ok, that confirms it is a reverse proxy issue, since PATCH and PUT use the same authorization.

[znetsixe]

I reproduced it on the hub. The 403 is a CORS preflight rejection emitted by FROST itself, not nginx:

Two conclusions:

• nginx forwards PATCH fine — an unauthenticated PATCH reaches FROST and gets a normal 401, identical to PUT. There is no method filtering
  in the nginx config (no limit_except, no WAF).
• With nginx fully bypassed, FROST advertises Access-Control-Allow-Methods: HEAD,POST,GET,OPTIONS. PUT, PATCH and DELETE are missing, so any cross-origin browser request using them fails preflight with 403.

What was done to fix it:

• Fix (infra/stacks/frost/compose.yml): added http_cors_allowed_methods: "GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS" to frost-http.
• PR: branch fix/frost-cors-methods → RnD/infra Unable to set `phenomenomTime` as an array of time instants #15 (https://git.wbd-rd.nl/RnD/infra/pulls/15) into main (no development branch exists —
  it's archived).
• Deployed: recreated frost-http via ./stack frost up -d frost-http (volumes intact).
• Verified: PUT/PATCH/DELETE preflights now return 200 (direct and through nginx); advertised methods now include ...,PUT,PATCH.

I didnt give delete rights to the write users. This belongs to the admin account only.