File / Image access authorization

Since 2.6.0 the access to files and images via the new static data endpoints was restricted depending on the restrictResourceAccess value at the time of the CRUD request, but for consistency with the old static data endpoints restrictResourceAccess should only have an effect at the time of attaching a file/image to an object. Also, getting an attached image depended on the object's roles, but this shouldn't be the case, because the read operation doesn't expose any of the object's data (and also a user could just use the old static data endpoints to fetch the same file/image without the object's roles being checked, making this behavior inconsistent). Both issues were corrected in this release.

The change tightens or loosens security depending on the combination of the type of request and restrictResourceAccess usage.

• Example for tightened security: When attaching a file/image to an object, the object's roles should be checked in any case, because a WRITE operation takes place on the object. Before this change, 1) it was only checked when the object's restrictResourceAccess value was true, and 2) it was false even when the class' restrictResourceAccess was true at the time the object was created. Now the object's roles are always checked when a user attaches a file/image to an object.

• Example for loosened security: When reading an attached file/image from an object, the object's roles were checked in case the object's restrictResourceAccess value was true (which was only the case when overwritten in the object directly - not when "inheriting" the value from the class). Now the object's roles aren't checked anymore in this case.

Cron Jobs

When using the static log methods from within a cron job, the module name that is displayed in the log message won't be Server Code anymore. Instead the name of the actual module, that contains the cron job, will be used.

Dynamic Roles

When Dynamic Roles where used (only possible in 3.0.0), the custom role check (a.k.a. overwritten isUserInRoles() method in Native Module) was not called when in another Native Module hook method or auth method the AOM.checkRoles() method was called. Since 3.0.1 this method is called.

You're only affected if you implemented your own isUserInRoles() method and assigned the Role Class to a MetaModel, and also used AOM.checkRoles() on that MetaModel / on objects of that MetaModel in your code.

apiomat.yaml

The SuperAdminPassword was removed from apiomat.yaml configuration. We recommend to manually delete the super admin password from your current apiomat.yaml. The entry is no longer needed. If you forgot your super admin password you are now able to get a password reset link to your configured super admin e-mail address. Just use the known password reset functionality.