160 likes | 175 Views
This content focuses on implementing multiuser protection in software design by following Unix principles and incorporating the Mediator pattern. Learn about user object restrictions, authentication methods, file reading enhancements, and group management strategies. The Mediator pattern is explained in detail, showcasing its benefits for promoting loose coupling and simplifying object interactions. Explore how to apply these concepts to enhance multiuser security in your software projects.
E N D
Multiuser Protection and the Mediator Pattern CSE432 02/22/2006 Matt Brenneke
Multiuser Protection • Follow Unix design, user and other • Users must have a login name • Basic authentication, user must provide login name and password
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
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!
Singleton - modified • Authentication • 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
Reading a file • Before • streamOut(ostream&); • Now • streamOut(ostream&, User*);
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*);
streamOut() changes • Check for User* == 0 • Call User::getUser() if true • isReadable() -> isReadableBy(user) • isReadableBy checks User->getLoginName against the Node’s owner.
Groups? • Groups have zero or more users. • A user can be a member of zero or more groups.
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
Mediator Overview • Intent • Encapsulate how a set of objects interact • Promote loose coupling • Allows you to vary interaction independently
Mediator Participants • Mediator • 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
Mediator Consequences • Limits Subclassing • Decouples Colleagues • Simplifies object protocols • Abstracts how objects cooperate • Centralizes control • May become monolithic itself
Applied to Groups Users Groups Mediator Grouping
Group Class members • static getGrouping() • static setGrouping(Grouping*, User*); • register(User*,Group*,User*); • unregister(User*, Group*, User*); • getGroup(string, index); • getUser(Group, index);
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