The GISquirrel connection file stores information about how the user will be authenticated by SQL Server or PostGIS. With SQL Server it is possible to use either Windows or SQL Server authentication (assuming your server is setup for Mixed Mode authentication). We usually find that Windows authentication is more stable. With PostGIS a named database account should be used.
Different levels of permissions are required for different GISquirrel operations. Therefore you can easily control the level of access for different users.
Importing layers and feature class administration operations require:
- permissions to create tables;
- permissions to create and alter views;
- write permissions on the arcquirrelmetadata table;
- write permissions on the arcquirreldomains table.
In SQL Server, adequate permissions for importing and administration can be assigned to a user by giving membership of these roles for the database: “db_datareader”, “db_datawriter” and “db_ddladmin” (or this one role "db_owner").
In PostGIS, permissions for importing and administration can be assigned by making a user a member of the "superusers" role. However this is a very powerful role, and we would advise creating specific roles (in pgAdmin or with the CREATE ROLE command), with appropriate privileges to the database and/or schema in which your spatial tables are going to be stored, and make each user a member of the appropriate role.
Editing a GISquirrel layer requires:
- write permissions on the table being edited;
- read permissions on the GISquirrelMetadata and GISquirrelDomains tables.
In SQL Server, adequate permissions for editing can be assigned to a user by giving membership of these roles for the database: “db_datareader”, “db_datawriter”. In PostGIS, appropriate roles should be created and assigned.
Viewing a GISquirrel feature class requires:
- read permissions on the GISquirrelMetadata table;
- read permissions on the table/view underlying the feature class.
In SQL Server, adequate permissions for viewing can be assigned to a user by giving membership of this role for the database: “db_datareader”. In PostGIS, appropriate roles should be created and assigned.
Fine grained permissions can be applied as well, for example to give a user read access to one table but not another, etc.
Modified 2/25/2013