One of the most common configurations out there is related to allowing web2project users to have access to only specific companies. While it’s not as simple as saying “users should only see things from their own company,” it’s not as complicated as you might think. Here’s how I’ve done it for various groups.

If you start with the basic roles, here are the step by step directions:

Role: Project Worker

Non-Admin Modules – Allow – Access, Add, Delete, Edit, View
Companies – Deny – Access, Add, Delete, Edit, View
Reports – Allow – Access, Add, Delete, Edit, View
Explanation: This gives access for a User to do anything they want on any of the non-admin modules *except* for Company. But since all of my Projects are assigned to a company, they can’t actually see anything other than the navigation menu and empty screens.

Results: I just created a new User with *only* this Role. The only Nav options visible are Projects, Tasks, Calendar, Files, Contacts, SmartSearch, Links, Reports. Under each, there is no data visible other than information not associated with any Company… for example, some of the Contacts.

Now, I got back and add permissions to individual users:

Companies – CaseySoftware, LLC – Allow – Access, View

Results: The User can now view all the information associated with my Company. This includes all of its Projects, Files, Contacts, etc. This user could even create new projects if they wanted, but only for this Company.

Now, since this is a ficticious contractor user, I add the following permissions:
Companies – Acme Anvil Corporation – Allow – Access, View

Results: The User can now view all the information associated with this additional Company. Everything they could do/see for CaseySoftware, LLC now applies here too. Now, if they were working on this company’s projects, they could log time against tasks, whatever.

Now let’s say I have a single Project within CaseySoftware, LLC that the person shouldn’t see, so I add these permissions:

Projects – Secret Anvil Development – Deny – Access, View, Add, Edit, Delete

Results: This prevents the User from seeing *anything* involved with this project. No Tasks, no Files, no Calendar Events.

Late last month, I received some bad news about web2project…

It turns out that web2project was vulnerable to a handful of select Cross Site Scripting (XSS: definition) vulnerabilities. While the attack vector was pretty specific to being an already authenticated user, it had the potential to be a major problem in a poorly configured system.

On the positive side, I say “was” because within 10 days of being notified of the problem – and the same day the vulnerability became public – we had a patched release out the door and available to users. We’ve spent the past month since encouraging them to upgrade. Of course, we further benefit from the fact that although the vulnerability does affect us, we’re not named in the report.

On the negative side, it did take us 10 days to close the vulnerability. The patch itself was available a few days earlier via Subversion but it might not have been enough. Further, we didn’t explicitly notify our users of a need to upgrade but since it was rolled with a handful of other major fixes, it appears that many people have upgraded already. Once again, we benefit from the very specific attack vector.

To make this process easier and faster in the future, as of v1.3, we can already detect if upgrades have been uploaded but not applied. For an upcoming release, we’re implementing a Drupal/WordPress-style means of notifying existing administrators thatan upgrade is available. In the meantime, watch this space or web2project’s page on Sourceforge.