Disabling Explorer Access To Share

[keidoo]

By default, the JSF Explorer (Alfresco web app) sets permissions on the Share space to everyone. In our implementation, we want to make sure that no one can access the Site space via the Explorer. Is it possible to remove the Everyone permission there without causing anything to break?

In our case, two managers will be responsible for all sites, and all sites will be private. Users should only be able to access the sites they are invited to, and some specific internal areas in alfresco (for which we would apply permissions in directly in explorer).

Thanks!

[norgan]

Hi,
a) maybe you can solve this by saying "only managers have access to Alfresco Explorer" - not sure, how that can be achieved, though
b) you could hack the "share" code to search not for "/sites" but for "/extensions/sites". Then leave the permissions on "/extensions/sites" intact, but block access to "/extensions"

let us know, How you make it work.

[systec]

We disabled 'public' access to Explorer (by IP) using a firewall between the web server and application server. All users using Share go via the 'public' web server while admin users have direct access to Explorer.

We customised Share quite heavily and found only one out-of-the-box component (which we use) that relied on a Share role, namely the Calendar component. It does a check against a role name rather than a privilege. Changing this bit of code allowed us to invite everyone to a site as a SiteConsumer. We now manage and implement our own security model directly on the site in the repository using Explorer which complements the Share security model.

[norgan]

Hi, could you "share" with us your "role" findings ? And what about Site creation ? is this blocked by you as well ?

Norgan

[keidoo]

So far, we're taking a slow and systematic approach to pairing down the permissions. So far removing the Everyone permission on the top level site permission seems to be working. We've also removed the read-only Everyone permission from each site created to the desired effect. No weird issues have cropped up as yet.

As for the creating site permission, we implemented the 'my-sites.get.html.ftl' patch that was posted in the forum earlier. It's not a complete solution, but it does what we need in the short term. I'll post more as we delve deeper.

[keidoo]

So far, we're taking a slow and systematic approach to pairing down the permissions. So far removing the Everyone permission on the top level site permission seems to be working.

Guess I spoke to soon. We've run into an issue where if anyone tries to request invite to a site Share throws all sorts of exceptions after the request is accepted. The problem disappears if the Everyone permission is added back to the Sites folder in Explorer. If the site manager sends invites and users accept, no exceptions are thrown.

[dward]

See https://issues.alfresco.com/jira/browse/ALFCOM-3283. This is fixed in HEAD.

[systec]

Norgan

The toolbar template of the calendar component checks against role name (<#if role = "SiteCollaborator" || role = "SiteManager">) to determine whether or not to display the Add Event button. Similarly in the helper.js file there is check against the role "SiteConsumer" in the function isUserPermittedToCreateEvents.

We altered this code to check against permissions instead; for e.g. (allowCreate = (obj.permissions.userAccess.allowCreate)? 'true' : 'false'. Our security model is applied via Explorer, in this particular case against the "calendar" space. While everyone is invited to the site as a SiteConsumer the permissions applied on the space provide the necessary permissions to create events.

In this particular implementation we don't allow site creation. A single pre-created site exists and a user logs directly into that site. The site dashboard in effect is the homepage and we've removed the header so that none of the links out of the site are available. We changed some of the dashlets from site-dashlets to user-dashlets so that the site dashboard can be customised (in effect becoming a user dashboard). Along with this we also changed the preset dashlets.

Hope that makes sense.