-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
8 tasks
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
added a commit
that referenced
this issue
Sep 23, 2024
if an initial_data_reference is passed for the product prefill flow
9 tasks
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
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
stevenbal
added a commit
that referenced
this issue
Oct 1, 2024
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 8, 2024
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
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
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
sergei-maertens
pushed a commit
that referenced
this issue
Dec 2, 2024
sergei-maertens
pushed a commit
that referenced
this issue
Dec 2, 2024
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
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
pushed a commit
that referenced
this issue
Dec 2, 2024
sergei-maertens
pushed a commit
that referenced
this issue
Dec 2, 2024
sergei-maertens
added a commit
that referenced
this issue
Dec 2, 2024
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
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
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 theSubmission
create endpointWe might want to remove the
Submission
in case this 403 happens, but I'm not 100% sure about thisWe might also have to add a check to verify that the object is of the same objecttype as part of the config
The text was updated successfully, but these errors were encountered: