[Chameleon] authorisation

Wed Sep 28 03:09:50 EDT 2005

Hi Jacob,

I see your point, but that would make maintenance of the HTML templates a lot of work, changes will have to go into all of the templates. Ofcourse you can include subtemplates, but still ...

I don't think a lot of widgets in Chameleon needs to be adapted, I am suspecting only widgets like XMLThemeLegend, depending on how they deal with non-existing layers. IMO that would be a general improvement of such a widget, not a specific change for adding authorisation.

For MAP files we could even work with Chameleon METADATA, for instance:

METADATA
  ..
  chameleon_allowed_groups "group1,group2"
  ..
END

Best regards,
Bart

Bart van den Eijnden
Syncera IT Solutions
Postbus 270
2600 AG  DELFT

tel.nr.: 015-7512436
email: BEN at Syncera-ITSolutions.nl
>>> "Jacob Delfos" <jacob.delfos at maunsell.com> 09/28/05 8:53 AM >>>
Bart,

We have a few sites that have custom querying abilities for different users; when visiting the website, the users are asked for a username and password (basic Apache authentication using .htaccess). In php, it detects the user that is visiting the site, making the search- and query tools return different results.

I actually once sent a message to the mapserver list asking if other people might see the use of having user-authentication at a layer or class level, but nothing came out of that. I was hoping for a solution where layers/classes would be fully ignored if the visitor to the website didn't occur in a list of users (the list of users being a layer/class variable). Since mapserver is designed to run in a web-environment anyway, the username can be counted upon to exist as an environment variable.

Without that, I think the most straightforward solution is to have a switch statement in a php file linked by index.phtml, which sets a different template and mapfile for each user. Something like:

-------------------- authentication.php --------------------------------------------------------------------------------------------
$username = $_SERVER['REDIRECT_REMOTE_USER'];

switch($username)
{
case "Bart":
$szTemplate = "c:/web/bart.html";
$szMapFile = "c:/web/bart.map";
break;
case "Henk":
$szTemplate = "c:/web/other.html";
$szMapFile = "c:/web/other.map";
break;
default:
$szTemplate = "c:/web/default.html";
$szMapFile = "c:/web/default.map";
break;
}
----------------------------(this code is untested)------------------------------------------------------------------------------------

I think that might be more straightforward than something that needs to be integrated into all widgets, because you cannot really disable a widget anyway without your template layout getting messed up. But those are just my thoughts.....

regards,

Jacob

» -----Original Message-----
» From: chameleon-bounces at lists.maptools.org 
» [mailto:chameleon-bounces at lists.maptools.org] On Behalf Of 
» Bart van den Eijnden
» Sent: 28 September 2005 14:32
» To: chameleon at lists.maptools.org
» Subject: [Chameleon] authorisation
» 
» Hi list,
» 
» I have been thinking a while about how to add authorisation 
» capabilities to Chameleon since this is one of the major 
» things missing from the Chameleon core, and I wanted to see 
» if other people have been thinking about this and what their 
» thoughts are.
» 
» As a use case, I would want to have different Chameleon 
» portals for different groups of people, without having to copy sites.
» 
» For instance, if a user belongs to a certain group, it should 
» not see certain widgets (or they should be disabled, that's a 
» choice to be made). Other things that come into play are, 
» seeing a different set of map layers.
» 
» This would mean changes to the UIManager I guess, which needs 
» to check in a database (could be sqlite just as for the 
» authentication stuff) if a widget should be visible/enabled 
» in the user's template.
» 
» Also, every user group would have a MAP file associated with 
» them. Right now the application has to set the right mapfile 
» argument for the CWCInitialize function. If we want to keep 
» this this way, the index.phtml file would have to take care 
» of setting the right MAP file. Or this responsibility could 
» be moved into Chameleon.php. For instance, if the application 
» developer just gives a MAP file as the second argument, the 
» normal processing will take care, if the MAP file argument is 
» empty, the right MAP file is looked up in a database table 
» (assuming the UIManager can access the rights object of the 
» user to check his rights).
» 
» Some of the widgets would need to get adapted, for instance 
» the XMLThemeLegend widget, but this could be as simple as not 
» showing themes and groups which cannot be found in the MAP 
» file (maybe this is already the current behaviour of this 
» widget?). So you have a master themes.xml for all layers 
» which can be present, and changing the MAP file would be 
» enough for changing what the user will see in the XMLThemeManager.

» 
» Am I missing things which would need to be done? Paul, would 
» you be interested in having something like this in the Chameleon core?
» 
» Best regards,
» Bart
» 
» Bart van den Eijnden
» Syncera IT Solutions
» Postbus 270
» 2600 AG  DELFT
» 
» tel.nr.: 015-7512436
» email: BEN at Syncera-ITSolutions.nl
» 
» _______________________________________________
» Chameleon mailing list
» Chameleon at lists.maptools.org
» http://lists.maptools.org/mailman/listinfo/chameleon
» 