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

Add validation to the Objects API prefill plugin to check if the user is the owner of the object #4398

Closed
Tracked by #4266
stevenbal opened this issue Jun 17, 2024 · 0 comments · Fixed by #4696
Closed
Tracked by #4266

Comments

@stevenbal
Copy link
Contributor

stevenbal commented Jun 17, 2024

The prefill plugin should check if the value of the auth attribute (this path will be configurable after #4396) is the same as the value of this authattribute for the authenticated user, if not, it should raise a PermissionDenied which should result in a 403 on the Submission create endpoint

We might want to remove the Submission in case this 403 happens, but I'm not 100% sure about this

We might also have to add a check to verify that the object is of the same objecttype as part of the config

@stevenbal stevenbal changed the title Add validation to the submission create endpoint to check if the user is the owner of the object Add validation to the Objects API prefill plugin to check if the user is the owner of the object Jun 17, 2024
@stevenbal stevenbal added this to the Release 2.8.0 milestone Jun 24, 2024
stevenbal added a commit that referenced this issue Sep 23, 2024
if an initial_data_reference is passed for the product prefill flow
stevenbal added a commit that referenced this issue Oct 1, 2024
if an initial_data_reference is passed for the product prefill flow
stevenbal added a commit that referenced this issue Oct 1, 2024
if an initial_data_reference is passed for the product prefill flow
stevenbal added a commit to open-formulieren/open-forms-sdk that referenced this issue Oct 1, 2024
…ass it with submissionCreate

previously this was not passed properly, resulting in the initialDataReference not being sent on submissionCreate
stevenbal added a commit that referenced this issue Oct 8, 2024
if an initial_data_reference is passed for the product prefill flow
stevenbal added a commit that referenced this issue Oct 10, 2024
the initial data reference is passed from the SDK to the backend as part of the login URL. In order to pass it as part of the submission create body, it must be propagated from the authentication start/return views back to the SDK
stevenbal added a commit that referenced this issue Oct 10, 2024
if an initial_data_reference is passed for the product prefill flow
stevenbal added a commit that referenced this issue Oct 10, 2024
the initial data reference is passed from the SDK to the backend as part of the login URL. In order to pass it as part of the submission create body, it must be propagated from the authentication start/return views back to the SDK
stevenbal added a commit that referenced this issue Oct 10, 2024
if an initial_data_reference is passed for the product prefill flow
stevenbal added a commit that referenced this issue Oct 14, 2024
the initial data reference is passed from the SDK to the backend as part of the login URL. In order to pass it as part of the submission create body, it must be propagated from the authentication start/return views back to the SDK
sergei-maertens pushed a commit that referenced this issue Dec 2, 2024
… True

this field is necessary to perform the initial data reference ownership check, which is performed when updating existing objects
sergei-maertens pushed a commit that referenced this issue Dec 2, 2024
when resetting values in the Objects API prefill form
sergei-maertens pushed a commit that referenced this issue Dec 2, 2024
* several cleanups of code
* also raise errors in prefill scenario
* explicitly raise error if auth attribute cannot be found at path
* add contextmanager to use VCR in setUpTestData
* remove REGISTRATION_OBJECTS_API_ENABLE_EXISTING_OBJECT_INTEGRATION feature flag (already added in 2.8.x)
* add separate fieldset for updateExistingObject in registration fields
* make authAttributePath disabled instead of not required if updateExistingObject is false
* use PropTypes.node instead of PropTypes.string for Objects API fields helptexts/labels
sergei-maertens pushed a commit that referenced this issue Dec 2, 2024
* raise PermissionDenied instead of ImproperlyConfigured in verify_initial_data_ownership in case of bad configuration
* let PermissionDenied errors bubble up during prefill, causing a 403
* show missing validation errors for other objects API prefill fields
sergei-maertens added a commit that referenced this issue Dec 2, 2024
The TargetPathSelect component is now decoupled from its possible
FieldArray parent, and the option label display is incorporated in
the component itself so that options no longer need to be pre-processed.

On top of that, it's now refactored to be based on react-select for
consistency in the UI, and separate stories have been added so we can
do (visual) regression testing/isolated development.

We use this component in a number of places now:

* the path to the auth attribute (no variablesMapping parent context),
  used in registration and prefill plugins for the Objects API
* the path for the generic Object Types V2 registration mapping, here
  a variablesMapping parent container/context is relevant and different
  form state management semantics apply
* the path to specialized AddressNL subfield mappings - a parent is
  relevant, but not within a bigger variable mapping so we can use the
  standard field assignment semantics of Formik.
sergei-maertens added a commit that referenced this issue Dec 2, 2024
The TargetPathSelect component is now decoupled from its possible
FieldArray parent, and the option label display is incorporated in
the component itself so that options no longer need to be pre-processed.

On top of that, it's now refactored to be based on react-select for
consistency in the UI, and separate stories have been added so we can
do (visual) regression testing/isolated development.

We use this component in a number of places now:

* the path to the auth attribute (no variablesMapping parent context),
  used in registration and prefill plugins for the Objects API
* the path for the generic Object Types V2 registration mapping, here
  a variablesMapping parent container/context is relevant and different
  form state management semantics apply
* the path to specialized AddressNL subfield mappings - a parent is
  relevant, but not within a bigger variable mapping so we can use the
  standard field assignment semantics of Formik.
sergei-maertens added a commit that referenced this issue Dec 3, 2024
Instead of prop-drilling, make sure to process validation errors at the
locations where the shape/structure is known and rely on the generic
mechanisms to pass/display the validation errors.

This also adds some JSDoc type hinting to the helpers because I keep
getting lost on what the expected shape of data/input is.
sergei-maertens added a commit that referenced this issue Dec 3, 2024
Instead of prop-drilling, make sure to process validation errors at the
locations where the shape/structure is known and rely on the generic
mechanisms to pass/display the validation errors.

This also adds some JSDoc type hinting to the helpers because I keep
getting lost on what the expected shape of data/input is.
sergei-maertens added a commit that referenced this issue Dec 3, 2024
Instead of prop-drilling, make sure to process validation errors at the
locations where the shape/structure is known and rely on the generic
mechanisms to pass/display the validation errors.

This also adds some JSDoc type hinting to the helpers because I keep
getting lost on what the expected shape of data/input is.
sergei-maertens added a commit that referenced this issue Dec 3, 2024
* Ensure we use the deserialized, strongly typed options in
  plugins
* Dropped unused error cases/flows that are obsoleted
* Made serializer options all required, since the prefill
  cannot possibly work without and must match the type
  definitions of the options.
sergei-maertens added a commit that referenced this issue Dec 3, 2024
* Ensure we use the deserialized, strongly typed options in
  plugins
* Dropped unused error cases/flows that are obsoleted
* Made serializer options all required, since the prefill
  cannot possibly work without and must match the type
  definitions of the options.
sergei-maertens added a commit that referenced this issue Dec 3, 2024
* Ensure we use the deserialized, strongly typed options in
  plugins
* Dropped unused error cases/flows that are obsoleted
* Made serializer options all required, since the prefill
  cannot possibly work without and must match the type
  definitions of the options.
sergei-maertens added a commit that referenced this issue Dec 3, 2024
* Ensure we use the deserialized, strongly typed options in
  plugins
* Dropped unused error cases/flows that are obsoleted
* Made serializer options all required, since the prefill
  cannot possibly work without and must match the type
  definitions of the options.
sergei-maertens added a commit that referenced this issue Dec 4, 2024
…n details

The important pattern is that certain validation checks run, not the
implementation details of the objects api prefill plugin. So, we
can properly isolate this by setting up a different plugin
registry and doing the dependency injection through a helper,
applying the same pattern as with registration plugins.
sergei-maertens added a commit that referenced this issue Dec 4, 2024
Dropped the bits that are not relevant.
sergei-maertens added a commit that referenced this issue Dec 4, 2024
The task/generic machinery takes care of deserializing the plugin
options and passes them to the hook for ownership verification, greatly
simplifying the code that needs to be implemented.
sergei-maertens added a commit that referenced this issue Dec 4, 2024
Properly mock the registry of plugins instead of having to rely on
particular demo plugins having certain behaviours or needing to
mock implementation details in tests.
sergei-maertens added a commit that referenced this issue Dec 4, 2024
* Converted the tests to make use of VCR for the actual implementation
  details of the ownership verification
* Simplified the tests and ensured they're unit tests focused around
  a single method. We have a generic pattern test that ensures the
  method gets called.
sergei-maertens added a commit that referenced this issue Dec 4, 2024
…refill-check-obj-permission

✨ [#4398] Check object ownership when creating submission
@github-project-automation github-project-automation bot moved this from Implemented to Done in Development Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants