• Import each directory into Eclipse as a seperate project
• In the jingle-mod directory, run com.jingle.Server.java

(unfortunately only runs from within Eclipse)

Point a REST client to the base url: https://localhost:8443 and use the following end points.

POST /signup - requires 'username', 'firstname, 'lastname', 'email' and 'password' - returns new user.)

POST /login - requires 'username' and 'password' - returns authentication key.

PUT /edit - requires 'userid' and 'authkey', with all other params being optional - returns updated user.

DELETE /delete - requires 'userid' and 'authkey' - returns whether successful or not

GET /user - requires either 'userid' or 'username' - returns user

I would create a repository containing containing different Roles, with either a one-to-many relationship with Users, or a many-to-many relationship (using a middleman join table, allowing a user to have many roles.) Each Role class could contain a list of methods which the User is permitted to do.

Roles could then inherit from each other, so a Guest role would have a certain subset of permitted operations. Member could then inherit all the methods from Guest and implement a further set of methods. Admin could then inherit all the methods from from Member and so on.

Before running any operations, a check would be made to see what roles the user has/belongs to, and whether the current operation is available to them. This could be as simple as saving a list of permitted operations in a repository/class and checking against it every time an operation is made.

For example:

delete(long id) {
  if(currUser.getRole().allowedToDelete() == true) {
    //delete
  } else {
    // throw Exception
  }
}

Alternatively, each role could be an interface which reveals all it's available methods. An admin might implement public void deleteUser(long id) with the full functionality, whereas the Guest role implements delete, but it just immediately throws an Exception.

A member might implement both public void deleteUser(long id) and public void deleteUser(long id, String authkey), with the first method throwing an exception and the second one actually deleting (but requiring the authKey).

 delete(long id) {
   try {
     currUser.getRole().operations().delete(id);
   } catch (UnauthorisedRoleException e) {
     // Handle
   }
 }

This could then be extended further with whole subsets of methods only being available to the relevant Roles.