- Import each directory into Eclipse as a seperate project
- In the
jingle-mod
directory, runcom.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.