On Thu, Dec 25, 2014 at 9:42 PM, Glen Mazza <glen.ma...@gmail.com> wrote:
> For the next release of Roller, I have some suggestions that I think will > increase adoption of Roller in corporate multi-blogger environments: > > 1.) I've brought this up before, but with 5.1 now out, I'd like to revisit > it. I'd like us to tighten up our security subsystem by moving from > multiple roles per user to just a single role (presently ADMIN, EDITOR, or > whatever custom role an integrator may choose to create.) Specifically the > userrole table (lines 28-32 here: http://svn.apache.org/viewvc/ > roller/trunk/app/src/main/resources/sql/createdb.vm? > revision=1625869&view=markup) would be dropped, and the rolename column > moved to the roller_user table. > > Roller is not the Oracle RDBMS, we do not have nearly enough permissions > (just 3 or so) to assign to those roles to warrant needing to store > multiple roles with each user, and code needing to maintain and query > multiple roles per user is much more confusing/complex and prone to > security holes. The current over-functional security architecture does not > provide easy confidence to integrators that Roller is secure to use, > harming adoption IMO. > > By way of analogy, if you're crossing a stream via a footbridge very high > up, you don't care about all the bells and whistles the footbridge has, you > just want it to be clearly strong and solid, even if it's plain-looking, > else you won't walk on it. Excessive bells and whistles may be great with > functionality but backfire with security as you lose confidence in the > product's ability to accurately calculate the proper permissions for each > user. > I think that is an unnecessary change that will have zero impact on adoption, will cause and schema churn and introduce bugs. I would be better to stick with the simple and conventional model, which is users have roles. 2.) Once that is done, it will be easier to determine who's an Admin, and > we have JIRAs already to allow Admins to drop users as well as obtain email > notifications of when users create or drop blogs. I think blog admins > would like this increased "driver's seat" functionality and it would make > them more likely to adopt Roller within their company. > The change will not make it easier to determine who is an admin. What could be easier than userManager.hasRole("admin", users)? 3.) (I've brought this up before, but I think I had bad replacement > suggestions at the time.) The titles of the three blog > permissions--LIMITED, AUTHOR, and ADMIN--may be harming Roller adoption in > companies. The permissions they contain is not the problem, it's just > their titles. "LIMITED" can be taking as degrading to any user granted > that role and if I were a boss I'd be concerned about getting two week > notices from employees given that ranking. "AUTHOR" has the problem in > that the person with that role frequently isn't the author but just > sanity-checking and publishing the blog article done by the person with the > LIMITED role, further irritating the latter. ADMIN is less polished a > title for the blog owner, and it conflicts with the title we give the blog > server administrator. > > Perhaps we should switch to CONTRIBUTOR, PUBLISHER, and OWNER (or > CO-OWNER)? CONTRIBUTOR has no negative connotation and can fully imply > authorship of the submitted blog articles. PUBLISHER is win/win, not only > is it a grander term than AUTHOR, at the same time it doesn't cause offense > to the CONTRIBUTOR by implying authorship in those cases where the > Publisher is just hitting the "Publish" button. OWNER (CO-OWNER on the > permissions assignment page) is a more polished term than ADMIN while at > the same time reserving the latter term for those special people at the > top, the blog server admins who choose to install Roller in their companies. I agree, limited is not a great term but I would disagree that we need any schema change to fix this -- its just a label. - Dave
