On 12/26/2014 09:30 AM, Dave wrote:
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.
I see it oppositely -- in my evalution, the presence of the userrole table is
the biggest handicap for Roller for getting greater usage in companies today,
the unwarranted clumsiness it adds to the security model makes it that much
harder for a security expert to analyze and assure that it's secure--namely,
that unwarranted roles are not getting attached to users. There's little I can
do for increasing Roller adoption, especially within companies, so long as we
keep that table. I'm thinking about forking Roller over this very issue. That
said, I have very little time to add to the project now anyway due to work
constraints, so I doubt I'll be going my own way on this. If you guys want to
keep this table, we'll keep it, but I think it's a unfortunate decision.
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)?
Oh, the call is simple, but what does it mean when someone has both the EDITOR and the
ADMIN role when they have no reason to have both, as the latter covers the former?
"Well, just make them admin!" But what if it was the ADMIN and not the EDITOR
role which was erroneously given? There's your security hole, borne from unnecessarily
allowing multiple roles for a user.
The problem with allowing multiple roles to be assigned to a user is that while
you think you've tightened up the security for a user by granting him just
EDITOR, if he happens to still have ADMIN in the userrole table he remains an
admin. And we don't have the user interface that makes it clear if a user has
multiple roles.
Another problem is that the above check "userManager.hasRole("admin",...)" is
inaccurate because it is the permissions that comprise the role that matter (indeed, we allow users
to create their own roles with whatever permissions attached.) If you give admin permission to an
EDITOR role or take away admin permission from the ADMIN role the call above is inaccurate. We're
supposed to be checking permissions, not roles--the role is just to be consulted to see which of
the four permissions the user has. You already have the level of indirection between permissions
and a role allowing for convenient assignment of permissions to users, given that we have just 3-4
permissions, multiple roles is unnecessary and a source of confusion and bugs.
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.
Yes, I was recommending changing the labels, no database schema or database
column value changes. (The database doesn't use the terms LIMITED, AUTHOR, and
ADMIN anyway but different ones.)
Glen
- Dave
