I have been learning to use the Security Subsystem and it works - but only for my shapefiles which have simple names that do not contain periods.
In users.properties:
test1=thepw,ROLE_1
test2=thepw,ROLE_2
In layers.properties:
..r=*
..w=*
massgis.TOWNS_POLYM.r=ROLE_1
massgis.GISDATA.TOWNS_POLYM.r=ROLE_1
test1 user logs in, sees all the layers in mapPreview including the 2 special ones. (good)
test2 user logs in doesn’t see TOWNS_POLYM in mapPreview (good), but I still see GISDATA.TOWNS_POLYM (bad)
The . in my layer name is throwing off the parsing of the config file in this instance.
I tried using a \ in layers.properties to escape:
massgis.GISDATA.TOWNS_POLYM.r=ROLE_1
but no luck.
Also tried massgis.“GISDATA.TOWNS_POLYM”.r=ROLE_1 and massgis.‘GISDATA.TOWNS_POLYM’.r=ROLE_1 no luck
Is there any way I can escape the period in the layer names in the layers.properties?
Could \ be implemented as an escape character? If I get past the config file will everything else be OK?
Or is there another creative solution? (besides going back in time and using underscores instead 
)
Hi Aleda,
As far as I know there is no way to escape periods in the feature type name. Looking at the code that does the parsing of the property file, i believe it could be smart enough to handle this case so I would say this is a bug. If you could file an issue in jira that would be much appreciated.
-Justin
Freeman, Aleda (EEA) wrote:
I have been learning to use the Security Subsystem and it works - but only for my shapefiles which have simple names that do not contain periods.
In users.properties:
test1=thepw,ROLE_1
test2=thepw,ROLE_2
In layers.properties:
*.*.r=*
*.*.w=*
massgis.TOWNS_POLYM.r=ROLE_1
massgis.GISDATA.TOWNS_POLYM.r=ROLE_1
test1 user logs in, sees all the layers in mapPreview including the 2 special ones. (good)
test2 user logs in doesn't see TOWNS_POLYM in mapPreview (good), but I still see GISDATA.TOWNS_POLYM (bad)
The . in my layer name is throwing off the parsing of the config file in this instance.
I tried using a \ in layers.properties to escape:
massgis.GISDATA\.TOWNS_POLYM.r=ROLE_1
but no luck.
Also tried massgis."GISDATA.TOWNS_POLYM".r=ROLE_1 and massgis.'GISDATA.TOWNS_POLYM'.r=ROLE_1 no luck
Is there any way I can escape the period in the layer names in the layers.properties?
Could \ be implemented as an escape character? If I get past the config file will everything else be OK?
Or is there another creative solution? (besides going back in time and using underscores instead )
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi Aleda,
As far as I know there is no way to escape periods in the feature type name. Looking at the code that does the parsing of the property file, i believe it could be smart enough to handle this case so I would say this is a bug. If you could file an issue in jira that would be much appreciated.
Well, the dot was chosen as the separator because it's illegal in a
type name, but sure, adding escaping processing in the parser should
not be hard. Where's my jira issue?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Aleda,
As far as I know there is no way to escape periods in the feature type name. Looking at the code that does the parsing of the property file, i believe it could be smart enough to handle this case so I would say this is a bug. If you could file an issue in jira that would be much appreciated.
Well, the dot was chosen as the separator because it's illegal in a
type name, but sure, adding escaping processing in the parser should
not be hard. Where's my jira issue?
Ah right, that makes sense... but i guess only for WFS 1.1. The dot in the name always seemed like a silly restriction anyways. Instead of an escape what about just making the parsing a bit different. Right now it blindly splits by ".". Could it not just take everything before the first period to be the namespace, everything after the last period to be the operation, and everything in between to be the feature type name? Or does that logic fall down for some cases?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
OK, I've created http://jira.codehaus.org/browse/GEOS-2726
I labeled it an enhancement, because Andrea is correct, it's not a bug -
it's our fault that we chose to use a illegal character. I'm grateful
that you're willing to accommodate us, you're too good to us
The idea of changing the parsing would work in our case.
-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wednesday, March 11, 2009 8:54 AM
To: Andrea Aime
Cc: Freeman, Aleda (EEA); geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Security subsystem layers.properties - is
it possible to escape the period in my unconventional layer names?
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Aleda,
As far as I know there is no way to escape periods in the feature
type name. Looking at the code that does the parsing of the property
file, i believe it could be smart enough to handle this case so I
would say this is a bug. If you could file an issue in jira that
would be much appreciated.
Well, the dot was chosen as the separator because it's illegal in a
type name, but sure, adding escaping processing in the parser should
not be hard. Where's my jira issue?
Ah right, that makes sense... but i guess only for WFS 1.1. The dot in
the name always seemed like a silly restriction anyways. Instead of an
escape what about just making the parsing a bit different. Right now it
blindly splits by ".". Could it not just take everything before the
first period to be the namespace, everything after the last period to be
the operation, and everything in between to be the feature type name? Or
does that logic fall down for some cases?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.