Permission Notes

Owned by Former user (Deleted)
Last updated: Aug 12, 2008Version comment
2 min read

On Aug 12, 2008, at 5:46 AM, Steve Swinsburg wrote:

> With the push to move everything to ContentHosting rather than each
> tool using their own storage method, we've come across an issue. In
> order for a user to be able to create content, they need the
> content.new permission for their role in the site. This is a
> permission that needs to be explicitly allowed. It's off by default.
>
> So if a new tool needs to allow a user to create content in
> ContentHosting (requires content.new ON), but the maintainer of a site
> doesn't want users to create content in the Resources tool (requires
> content.new OFF), how does one get past this?
>
> The resources tool could be hidden, but what if the maintainer didn't
> want it hidden. I think we need a finer grained level of permissions
> for ContentHosting rather than all on or all off. Or am I missing
> something?

Jim Eng replies:

Other tools such as assignments, melete and some of the OSP tools do some version of what you're describing. There are several possible ways this can be accomplished. For example:

  • your tool or service uses a security adviser that allows users to create a resource in a place that the user is not ordinarily allowed to. The semantics are that a user is granted a permission that the user does not necessarily have in contexts other than that.
  • you create a special collection in a place not browsable with the resources and grant the access role permissions to create, revise and view resources there.
  • use the filepicker as a helper in the other tool. The default behavior is now that attachments created in the site can be viewed by members of the site. If the user has permission to create some other entity, she has permission to add an attachment to it if your tool enables that.

I'm pretty sure there are other possibilities if none of these seems to fit your use case.

Glenn Golden adds:

Steve - if your tool is making calls to the content hosting API to manage the content, then you need to use a security advisor around your content hosting calls. This lets you re-define the security of the content hosting api calls to whatever you desire for that call. You can do your own security, then just let content hosting do the work of managing your content without its security.

If you are letting users put content into content hosing via the resources tool directly, this won't work. Then the access is completely under content hosting's security.