1. Multiuser Protection and the Mediator Pattern
CSE432
02/22/2006
Matt Brenneke

2. Multiuser Protection Follow Unix design, user and other
Users must have a login name
Basic authentication, user must provide login name and password
Follow unix design (again)
2 types of permissions for any node, those for the user, and those for other.
We will address group later
Treat User and login name the same, one to one mapping
So how to we model a User? Using an object of course!

3. User Object Restrictions
Clients can’t create User objects at will
User object must always have a valid login name
Client can’t instantiate a user w/o name and password
These requirements push us towards a creational pattern at a minimum for the User object.
We need a secure way to create the object, without exposing the Constructor to a client.

4. Creation Abstract Factory? No, Families of Objects
Builder? No, different representation
Factory Method? No, similar to Abstract Fact.
Prototype? No, What, not How
Singleton? Bingo!
So lets look at the creational patterns.
Abstract Factory focuses on families of objects, which we don’t have.
Builder focuses on creating complex objects with the same interface and different representations
Factory Method is to similar to Abstract Factory, without the focus on families
Prototype focuses on what gets instantiated, now how it gets instantiated
Singleton protects how the object gets created, and insures only one object is created at any given time.

5. Singleton - modified Authentication Multiple User objects
Call Intantiate() logIn(), and add user and password parameters.
Can return 0 if user or password is invalid
Client can’t change logIn() by subclassing User
Multiple User objects
Keeps a hash of User objects
Only one User object per username
Patterns aren’t meant to domineer your design, just assist in it’s construction. We can change it!
We need to add authentication to verify only valid users are created.
Unlike a Constructor, logIn can return 0 if there is an invalid user or password
By keeping our constructor private, a client can’t change the logIn process by just subclassing User.
But the basic singleton pattern only allows one Instantiation of the object period. What about more than one user being given at a time?

6. Reading a file Before Now streamOut(ostream&);
streamOut(ostream&, User*);
Now when we read a file, we need to pass a user so the node can verify that the client has permission to read it
Since creating a User object is protected, the Node can trust that any User object passed in is authentic.
But having a client pass in the same User every time it accesses the filesystem can be a nuisance if the application is working on behalf of only one user.

7. Common case Give the user parameter a default value
void streamOut(ostream&, const User* = 0);
Add setUser and getUser functions to the User class
static const User* User::getUser();
static void User::setUser(const User*);
The login process for a user should call setUser once it has obtained a valid User object.

8. streamOut() changes Check for User* == 0
Call User::getUser() if true
isReadable() -> isReadableBy(user)
isReadableBy checks User->getLoginName against the Node’s owner.
Node functions now must be modified to check if a User object was passed in. If one was passed in, use it, otherwise call the getUser function.

9. Groups? Groups have zero or more users.
A user can be a member of zero or more groups.
Glossed over the UNIX concept of groups earlier. Now it’s time to address them.
Second item implies reference but not aggregation: Deleting a group does not delete its constituents.

10. Group Object Representation
Composite? No
Groups aren’t recursive
A user might belong to several groups
Don’t want to treat groups and users the same
Mediator!
Relationship between groups and nodes is complex and variable
Needs loose coupling
No groups of groups
Not strictly hierachial
Can’t log in as a group, don’t want to pass group objects around
What can we use then? Mediator!

11. Mediator Overview Intent Encapsulate how a set of objects interact
Promote loose coupling
Allows you to vary interaction independently

12. Mediator Participants
Interface for communicating with Colleagues
ConcreteMediator (optional)
Implements coordination between Colleagues
Knows and maintains its Colleagues
Colleague classes
Knows its mediator class
Communicates with Mediator only
When colleagues work with only one mediator there is no reason to abstract the mediator class

13. Mediator Consequences
Limits Subclassing
Decouples Colleagues
Simplifies object protocols
Abstracts how objects cooperate
Centralizes control
May become monolithic itself
Meidator pitfall is that it has a tendency towards monolithic Mediator classes.

14. Applied to Groups Users Groups Mediator Grouping
Instead of a bunch of calls directly between users and groups, all interaction goes through the mediator
Why user and not node?

15. Group Class members static getGrouping()
static setGrouping(Grouping*, User*);
register(User*,Group*,User*);
unregister(User*, Group*, User*);
getGroup(string, index);
getUser(Group, index);
Get and set groupings are static to allow mappings to be gloabally accessible and settable
By replacing the Grouping object at run-time it’s possible to change the mapping in one move.
setGrouping, register, and unregister are protected operations, so they must be called with an authorized User as their final argument
Finally, getGroup and getUser identify associated groups and users.

16. Wrapping Up Chapter 2 Composite provides structure
Proxy provides symlinks
Visitor allows new, type specific functionality
Template Method provided basic protection
Singleton and Mediator combine to allow full Multi-user protection