- Disable Rails/HttpPositionalArguments completely.
It is often not relevant and breaks specs when rubocop -a is used.
- Support excludedAttributes for all enpoints in SCIM Server API
- Fix excludedAttributes to handle nested attributes correctly. e.g. name.givenName
- Respond with 403 whne User can't be deleted due to lack of permissions.
- Refactor scim related code by removing duplication where possible.
- Remove BasicAuth from supported auth schemes.
- Add specific specs to test SCIM authentication.
- Extend specs.
This is making the interface of BaseCallable more consistent.
Previously it was unclear, whether the params passed to perform
should be used to reference parameters or whether the attribute accessor
should be used. Different code used different approaches.
To apply this change more consistently, BaseContracted also removed
params from the methods called inside its own perform method, e.g.
before_perform or after_validate.
At a later point we might consider removing this argument from other large
inheritors as well, for example `BaseServices::SetAttributes#set_attributes`.
- Enable SCIM Patch.
- Use user_auth_provider_links instead of users.identity_url.
- Extend SCIM ActiveRecord base scopes to join and preload appropriate associations.
- Set a stub for user.firstname and user.lastname if they are not provided by SCIM client.
- Handle user unique constraint vialation according to SCIM spec.
- Move user_auth_provider_links association to principal as group needs it as well.
- Set user.mail dynamically from the list of emails provided by SCIM client.
- Change BaseServices::Create contract to accept model instance as a constructor parameter.
It gives an option to build associations before model creation.
- extend SCIM server API schema to include externalId.
- Adjust specs.
Previously we only got the slug name of the provider
as a string, which doesn't allow to further use the provider.
Converting it back into its AR representation allows to call
further methods on it, e.g. checking support for certain capabilities.
In order to keep this constructor flexible and be able to simply
provide class names that warrant replacing, performed a refactor
on the internal works.
I don't believe recursion is strictly necessary and if anything, I feel
a simple "hijack" or "focus" on replacements one by one without the need
for instantiation is simpler to wrap my head around.
Made sure to add some specs to cover both constructor signatures and
expected behavior.
ulferts