8 Replies Latest reply on Apr 16, 2010 5:05 PM by tmaurer

    Making the default content creation more secure

      I noticed from playing with the evaluation version (license PO soon, guys), that it's incredibly easy to circumvent the space/social group permission system.

       

      For instance,

       

      I've created a document in this Feature Discussion space (http://www.jivesoftware.com/jivespace/docs/DOC-10835) that anyone can edit.

       

      I didn't change any of the default settings.

       

      In our potential intranet, this means that users need to know to either say "Only me" or know the exact people who they want to grant edit rights.  This is one more thing to learn if Jive is new to them!

       

      There is no way (that I can see) that a user can say "All members of this space", or "All administrators of this user group" can edit this document, and certainly no way of just defaulting to "Only me".

       

      Maintaining edit permissions on documents when someone joins or leaves a group seems to be hard work in this model.

       

      Maybe this is by design, but I'd like to see a justification for it?  Can you help

       

      Cheers

       

      Nick Drew

      Consultant

      ThoughtWorks

        • Re: Making the default content creation more secure
          nick

          Hi Nick,

           

          I'd like to clarify a few things from your question below. Feel free to follow up with additional questions if you have any.

           

          I've created a document in this Feature Discussion space (http://www.jivesoftware.com/jivespace/docs/DOC-10835) that anyone can edit.

           

          When you say anyone can edit, that means anyone that has the create document permission in the feature discussion space. When you create content in Jive, you first choose a place (space, project, group). That place will dictate who can see / comment on / edit / etc. that piece of content. For documents specifically, we offer further authorship controls, to restrict the authors on that document to a subset of users.

           

          In our potential intranet, this means that users need to know to either say "Only me" or know the exact people who they want to grant edit rights.  This is one more thing to learn if Jive is new to them!

           

          There is no way (that I can see) that a user can say "All members of this space", or "All administrators of this user group" can edit this document, and certainly no way of just defaulting to "Only me".

           

          Maintaining edit permissions on documents when someone joins or leaves a group seems to be hard work in this model.

           

          User's should never have to deal with the exact people who they want to grant edit rights. The edit rights come from the place, all user's have to do is decide where to create their content. Then, as permissions can change for the place, or people join / leave the group, the edit rights on the content adjust accordingly.

            • Re: Making the default content creation more secure

              Hi Nick!


              I've created a document in this Feature Discussion space (http://www.jivesoftware.com/jivespace/docs/DOC-10835) that anyone can edit.

               

              When you say anyone can edit, that means anyone that has the create document permission in the feature discussion space. When you create content in Jive, you first choose a place (space, project, group). That place will dictate who can see / comment on / edit / etc. that piece of content. For documents specifically, we offer further authorship controls, to restrict the authors on that document to a subset of users.

               

              In our potential intranet, this means that users need to know to either say "Only me" or know the exact people who they want to grant edit rights.  This is one more thing to learn if Jive is new to them!

               

              There is no way (that I can see) that a user can say "All members of this space", or "All administrators of this user group" can edit this document, and certainly no way of just defaulting to "Only me".

               

              Maintaining edit permissions on documents when someone joins or leaves a group seems to be hard work in this model.

               

              User's should never have to deal with the exact people who they want to grant edit rights. The edit rights come from the place, all user's have to do is decide where to create their content. Then, as permissions can change for the place, or people join / leave the group, the edit rights on the content adjust accordingly.

              What you say chimes exactly with how I would expect the software to behave.  But there's something in the implementation that doesn't seem to be quite right.

               

              Here's what caused me to get slightly confused:

               

              1. Take a standard demo installation (we use the rpm jive_sbs_employee-4.0.3.RHEL-5.x86_64.rpm) on Centos 5.1
              2. Install using all the defaults - so you should just have one administrator
              3. Add two users, Punter, and Editor
              4. Log in as Editor - create a Group (e.g. "ForConsumptionOnly")
                •      This group should be "Member's only", and only allow Documents to be added.
                •      At this point the group should have Editor as administrator, and no members.  If Editor isn't an administrator, log in as admin and make it so.
              5. Editor, create a document (e.g. "ReadOnlyForRegisteredUsers" - add some content, make it as editable by "Anyone" (the default!)

               

              So that's the fixture for this test.  We now have Punter and Editor  as "Registered User" and Editor as administrator of a "Member's only group", Punter is NOT a member of this group.

               

              At this point, I think you'd agree that since Punter is not a member of the group, they should NOT be able to edit the document.

               

              However, in my tests, Punter CAN edit the document.  It's this that I find perplexing.  Now Punter cannot ADD a new document.  But, hey, they don't need to if they can just change one thats there.

               

              And all this just by following the defaults.

               

              As I said, this might be by design, but I'd like to know why it is this way - my mental model is like yours, and it's confusing when it doesn't match implementation.

               

              Cheers

               

              Nick