Java and Spring MVC Design and architecture for a social art sharing site

Question

I want to get some practice building an application in Java using Spring MVC. I have some questions regarding designing and implementing the idea that I have.

Here is what I am trying to develop and below you will find my design questions.

A user navigates to a website that hosts artwork (html5 canvases) And has the ability to use it as a guest. The guest or a logged in user can search other people's artwork. The site allows for the end user to be able to create artwork and share it with the world by publishing it and generating a permanent URL for the resource. Anyone can access the artwork unless it has user/password protection that the author of the artwork can decide if needed. Only the author of the artwork should be allowed to edit his artwork. Users will be able to comment under images that belong to them or other users. Guests need to be members to make comments on other people's artwork or creating their own images and permanent urls.

Questions:

I have very limited experience in webdevelopment. I'm only a database vetran. :-( So I appologize if these questions are noob like. I know some spring and Java.

1). Should I have 2 kinds of template pages? One for author and one for otheruser/guest for every user's artwork page? Not sure how this is handled in other popular applications.

2). How should I manage this through spring security. Each user can only edit his artwork page and not someone else's. In documentations I just see examples of ROLE_USER/ROLE_ADMIN. That seems way too basic for my need. Not sure where to begin and fit this for my use-case where collaboration is involved. Any tutorials that present this type of design would be really helpful.

Thank you in advance.

Answer 1

Different Templates?

You could use the same template for showing the view for the author and the guest, and modify some elements on the page based on the current user's permissions to that page's artwork. You'd only create two separate pages if the different views would be radically different, and it's more trouble than it's worth to make the page dynamic.

Spring Security for Authorization

Spring Security handles authentication (who is the current user?) and authorization (is the current user allowed to do this?). Here, we're talking about authorization.

There are different ways you can use Spring Security for authorization. One way is to use a chain of voter strategies to decide if the user is allowed to perform an action (AccessDecisionManager). Another is a full-blown ACL implementation where you maintain a set of tables that describe a person's access permissions for each resource you want to lock down. Reading from the ACLs is straightforward, but it's on you to maintain these tables. Every time permissions change, or secured objects are created, you have to insert or update the ACLs. Scroll down here to see an example.

Recommedation: Keep it Simple

I recently evaluated the different methods of authorization using Spring Security, and decided to just use the user's principal myself, and hit the database to see if the user has permissions to a resource. Spring Security is complex, and if you introduce a bug in your ACL-managing code after the site has been live, good luck tracking it down. The bug will only exist for those specific records for which the ACLs were modified.

I'd keep it simple. Create a SecurityManager with methods:

public boolean canViewArtwork(String userPrincipal, Long artworkId);
public boolean canEditArtwork(String userPrincipal, Long artworkId);

Then, call these methods when you need to do a security check. This is the sort of code you can walk away from and come back to later and understand.

Use Permissions, Not Roles

Notice the SecurityManager is checking permissions, not roles. Projects always start with two roles, "user" and "admin". Down the road, these lines always start to blur, and you end up with conditionals all over the place. You can still initially have the two roles in the system, but the SecurityManager will be the only place that deals with them. If you end up adding a third role - no problem, only your SecurityManager needs to change.