Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide visibility settings to simplify process deployment, listing and description #446

Open
8 tasks
fmigneault opened this issue Jul 5, 2022 · 0 comments
Assignees
Labels
good first issue Good for newcomers project/OGC Related to OGC testbeds or relavant projects. triage/enhancement New feature or request triage/feature New requested feature.

Comments

@fmigneault
Copy link
Collaborator

fmigneault commented Jul 5, 2022

Description

Weaver supports a visibility field that originates from OGC Testbeds 14 when deploying a process to make it private or public.
By default, private visibility is employed to avoid unintentional exposure of a process that should not be revealed.
Because of this, each new deployment must explicitly include visibility: public in the payload to make this process available right away.

Given that this field is not represented in OGC-API - Processes (not core feature) nor easy to identify by new users, this leads to a confusing situation where a successfully deployed process returns forbidden when access to it is attempted afterwards. Most users cannot identity the cause of forbidden access is the visibility (rather than some platform authentication), and that it simply needs to be set (or reset with PUT /processes/{processID}/visibility endpoint) as public.

A setting weaver.process_visibility_default = private | public could be made available from the INI configuration such that a platform that uses other means of access control to processes (or if we simply want weaver processes to be public at all times), can override the default private visibility. This default would be used during new process deployments, but would leave the visibility feature active if private was explicitly provided. Another option could be to add weaver.process_visibility = true | false allowing to remove visibility checks altogether (ie: everything behaves as if public regardless of actual visibility applied, as in core OGC-API - Processes).

To Do

  • add weaver.process_visibility = true (default setting) in example INI
  • add weaver.process_visibility_default = private (default setting) in example INI
  • use weaver.process_visibility_default setting when resolving a process deployment if visibility field was omitted
  • validate value against allowed visibility values
  • conditionally add visibility endpoints to API when weaver.process_visibility = true
  • conditionally skip raising forbidden access to processes if weaver.process_visibility = false
  • conditionally list all processes regardless of visibility if weaver.process_visibility = false
  • conditionally remove visibility field from process descriptions and summaries if weaver.process_visibility = false

References

@fmigneault fmigneault added triage/enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers triage/feature New requested feature. project/OGC Related to OGC testbeds or relavant projects. labels Jul 5, 2022
@fmigneault fmigneault self-assigned this Jul 5, 2022
@fmigneault fmigneault removed the help wanted Extra attention is needed label Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers project/OGC Related to OGC testbeds or relavant projects. triage/enhancement New feature or request triage/feature New requested feature.
Projects
None yet
Development

No branches or pull requests

1 participant