Spring Content S3 - CannedAccessControlList support about spring-content HOT 7 CLOSED

@FeDLviv, I realized that there is an option available to us today actually. You could, I think, provide a Store customization to add a setContentACL method to your Store interface(s). I don't know why I didn't think of this previously so I apologize. But, anyways, you should be able to do something like this:-

public interface AccessControllable<T> {
	void setContentACL(T entity, AccessControlList acl);
}

@Configuration
public class StoreConfiguration {

	@Bean
	public AccessControllableImpl accessController(AmazonS3 s3) implements AccessControllable, StoreExtension {

		public void setContentACL(T entity, AccessControlList acl) {
			// use entity and s3 client to set given ACL on content object  
		}

		@Override
		public Set<Method> getMethods() {
			Class<?> clazz = Renderable.class;
			Method method;
			try {
				method = clazz.getMethod("setContentACL", Object.class, AccessControlList.class);
				Set<Method> methods = Collections.singleton(method);
				return methods;
			}
			catch (Exception e) {
                    ...
			}
			return Collections.emptySet();
		}

		@Override
		public Object invoke(MethodInvocation invocation, StoreInvoker invoker) {
			return this.setContentACL(invocation.getArguments[0], invocation.getArguments[1]);
		}
	}
}

public interface YourStore extends ContentStore<YourEntity entity, UUID>, AccessControllable {
}

Should allow you to call:

store.setContentACL(entity, acl);

Apologies for the overly cumbersome way of adding an extension (the getMethods and invoke methods). This needs tidying up but it should work.

from spring-content.

If there is a requirement for it then we can definitely look into this @FeDLviv. Are you thinking this could be another entity annotation?

from spring-content.

Are you thinking this could be another entity annotation?

Even better if this field with special enum and user should be able to set access level, before saved file.

from spring-content.

Sorry for the inactivity on this issue. I was thinking about this one a little more.

If you are associating content with Spring Data Entities (and that content is being stored in S3 clearly). I notice your example is PublicRead so is that content being actively accessed directly via another API (the S3 API I would presume?) in addition to the Spring Content API?

Or is this just about setting an appropriate ACL on the content so that if it happens to be accessed it can't be messed with

Setting an initial ACL upon creation is fine (and easy) but presumably, you would you expect the ACL to be changed appropriately on the s3 object if the ACL field on the Entity ever changed.

from spring-content.

I notice your example is PublicRead so is that content being actively accessed directly via another API (the S3 API I would presume?) in addition to the Spring Content API?

This example from my project without using Spring Custom, only Spring Data and AWS SDK for Java. User choose access level (private or public URL for read), before saved file.

you would you expect the ACL to be changed appropriately on the s3 object if the ACL field on the Entity ever changed.

It would be nice to have this opportunity, but I would just have to set the level of access before record a file. Thereafter ignore all attempts changes value (for example - base entity without setter for this field or annotation Column with updatable = false)

from spring-content.

More thoughts.

1. ACLs are complex objects. PublicRead is really just a grant to the AllUsers Grantee. Others use cases may require permissions to be set on more than one Grantee. It is not clear to me how we would represent this on an Entity. Separate annotated fields perhaps? These would have to be serializable by Spring Data.

2. I feel that only setting ACL upon creation would be of limited use to others.

As already discussed, if we add ACL logic to the S3 store's setContent implementation (for example) then when the entity's ACL field(s) are updated there is nothing to call the setContent in order to update the content object's ACL. This would only work for new Entities.

I also considered whether, or not, it would be possible to orchestrate this from a Spring Data REST event handler but then realized you have the opposite problem in that, for new entities, the content object wouldn't yet exist and therefore nothing to set the ACL on yet!

So, neither approach will work. One only handles new objects and the other only handles existing objects.

So I am now considering if we should have a specialization of ContentStore, S3ContentStore, with ACL management methods like setContentACL(S entity) and getContentACL. Potentially, we could also layer Spring Content REST extensions on top of this that add a request mapping for an ACL resource. So, for example /myentity/12345/acl would address the ACL for the content associated with entity 12345.

Thoughts?

Flipping things completely on their head. I am also wondering whether you would need any of this at all IF you adopted Spring Content REST in addition to Spring Content S3. If you adopted Spring Content REST then access to the S3 objects would be via the Spring Content REST endpoints, not the S3 endpoints (you could enforce this by denying all access except for the access key used by your application). You could then secure the endpoints for your exported Content Stores using typical spring security approaches as shown in this Spring Data REST example.

Curious if this would work for you, or not. And if not, why.

from spring-content.

Many thanks, it's a great option.

from spring-content.