[Geoserver-users] newbie questions about services configuration

GeoServer GeoServer User
1

Hello everyone on the list.
I’m just starting to know Geoserver and I have two major questions about the services configuration

1 - WMS and WFS: which xml files do manage the config of these services, and where are they located? I can’t figure it out from the demos inncluded in the geoserver webapp. Something can be made through the web interface but, ie, where do I set queryable layers, or nillabel property,etc.?

2 - WFS-T: I’ve seen there are service.properties and user.properties inside data/security, but which users and roles do they refer to? I would like to manage the “Service Level”, the Input/Update/Delete actions for the single layers and for roles… So, the same question as above.

Thanks,
Giovanni

2

On Friday 01 February 2008 13:20:41 G. Allegri wrote:

Hello everyone on the list.
I'm just starting to know Geoserver and I have two major questions about
the services configuration

Great, welcome to Geoserver :slight_smile:

1 - WMS and WFS: which xml files do manage the config of these services,
and where are they located? I can't figure it out from the demos inncluded
in the geoserver webapp. Something can be made through the web interface
but, ie, where do I set queryable layers, or nillabel property,etc.?

It's probably wise not to modify the xml files directly. The web interface
lets you configure the information being exposed under the 'data' section.

2 - WFS-T: I've seen there are service.properties and user.properties
inside data/security, but which users and roles do they refer to? I would
like to manage the "Service Level", the Input/Update/Delete actions for the
single layers and for roles... So, the same question as above.

The users.properties file can define any roles you want, they are free text.
That is, any roles you specify will exist as soon as you use them in the
config file. The only role with special meaning is ROLE_ADMINISTRATOR, which
of course is required for users to access the configuration console.
service.properties then refers to the roles defined in the users file. You
won't get a warning if there are roles mentioned in one file but not the
other, so keep an eye out for that. Conveniently, these files are reloaded
automatically if you modify them while Geoserver is running, so it's pretty
easy to play around with them.

Hope this helps,
-David Winslow

Thanks,
Giovanni

!DSPAM:4040,47a36302256871628642973!

3

Thanks David.

It’s probably wise not to modify the xml files directly. The web interface
lets you configure the information being exposed under the ‘data’ section.

I know I have to be careful in modifying the files, but I would like to have a more fine grained then what permitted from the web interface: set queryable layers, nillable, etc (I’m used to the METADATA tags in Mapserver mapfiles).If it’s all controllable from the web interface… I haven’t discovered how yet :slight_smile:
Anyway, do these files exist, or is this low-level control serialized in non human-readable formats?

About the second question, I make a scenario: I have a user that will access wfs-t from a client (gvSIG i.e.). I want him to be autheticated with username and password, which is mapped to ROLE_X, which is enabled to do Insert and Update but not Delete on a specific layer (only one beneath all the WFS layers). Is it possible to manage such a fine grained context?

Thanks again

Hope this helps,
-David Winslow

Thanks,
Giovanni

!DSPAM:4040,47a36302256871628642973!

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

4

G. Allegri ha scritto:

Hello everyone on the list.
I'm just starting to know Geoserver and I have two major questions about the services configuration

1 - WMS and WFS: which xml files do manage the config of these services, and where are they located? I can't figure it out from the demos inncluded in the geoserver webapp. Something can be made through the web interface but, ie, where do I set queryable layers, or nillabel property,etc.?

If it's not settable thru the web UI, it's not there (minus a very small
exception that I won't mention). When you load a layer in geoserver it's
automatically available in all services. If WFS is active, it will be
downloadable, if WFS-T is active (it is by default) it will be modifiable as well. Same goes for WMS, if it's active, it's active 100%,
all output formats are there and it's queriable (coverage layers are not
at the moment).

The kind of granular configuration you're looking for will eventually be
there when we throw away the current configuration subsystem and create
a new one. With the current one we have to modify 12 files to add a
single option to the UI and config, it's simply too painful to do unless
someone really wants it and is willing to either code the change
himself or pay to have someone of us do it.

When that will happen, I don't know... so far we managed to collect
sponsoring for other features that do not touch the UI so we did not
touch it. I hope we'll manage to get away with the current UI and
config by the end of 2008, but that's just a hope.

Cheers
Andrea

5

G. Allegri ha scritto:

Thanks David.

    It's probably wise not to modify the xml files directly. The web
    interface
    lets you configure the information being exposed under the 'data'
    section.

I know I have to be careful in modifying the files, but I would like to have a more fine grained then what permitted from the web interface: set queryable layers, nillable, etc (I'm used to the METADATA tags in Mapserver mapfiles).If it's all controllable from the web interface... I haven't discovered how yet :slight_smile:
Anyway, do these files exist, or is this low-level control serialized in non human-readable formats?

The control you're looking for simply does not exist, code would have
to be developed in order to provide it.

About the second question, I make a scenario: I have a user that will access wfs-t from a client (gvSIG i.e.). I want him to be autheticated with username and password, which is mapped to ROLE_X, which is enabled to do Insert and Update but not Delete on a specific layer (only one beneath all the WFS layers). Is it possible to manage such a fine grained context?

HTTP basic authentication is possible, but not control on the sigle
transaction elements. At the moment the services.properties file
allows you to control which service.method each role is allowed to
access, for example:

wfs.transaction=WFS_UPDATER

but that's it. It applies to all layers (no per feature type control)
and does not consider transaction sub-elements.

The current security system was developed as a proof of concept
and it has been kept as is because of lack of funding (and because it's
anyways better than the nothing 1.5.x had).

Hopefully in the next few months we'll get sponsoring to have per
layer control but it will be generic read/write control, not operation
oriented one.

There are OGC security proxies around that might allow more fine grained
control than what geoserver provides out of the box, there is one
from DeeGree and one from 52north. I've never tried to use them
but they may provide what you're looking for.

Cheers
Andrea

6

Thank you very much Andrea, you covered all the answers I needed. At the moment the only solution to all my needs is a proxy to manage the access poloicies to the different services.
I hope I will find sponsors to help you in developing what I was asking for :slight_smile:

Giovanni

2008/2/2, Andrea Aime <aaime@anonymised.com>:

G. Allegri ha scritto:

Thanks David.

It’s probably wise not to modify the xml files directly. The web
interface
lets you configure the information being exposed under the ‘data’
section.

I know I have to be careful in modifying the files, but I would like to
have a more fine grained then what permitted from the web interface: set
queryable layers, nillable, etc (I’m used to the METADATA tags in
Mapserver mapfiles).If it’s all controllable from the web interface… I
haven’t discovered how yet :slight_smile:
Anyway, do these files exist, or is this low-level control serialized in
non human-readable formats?

The control you’re looking for simply does not exist, code would have
to be developed in order to provide it.

About the second question, I make a scenario: I have a user that will
access wfs-t from a client (gvSIG i.e.). I want him to be autheticated
with username and password, which is mapped to ROLE_X, which is enabled
to do Insert and Update but not Delete on a specific layer (only one
beneath all the WFS layers). Is it possible to manage such a fine
grained context?

HTTP basic authentication is possible, but not control on the sigle
transaction elements. At the moment the services.properties file
allows you to control which service.method each role is allowed to
access, for example:

wfs.transaction=WFS_UPDATER

but that’s it. It applies to all layers (no per feature type control)
and does not consider transaction sub-elements.

The current security system was developed as a proof of concept
and it has been kept as is because of lack of funding (and because it’s
anyways better than the nothing 1.5.x had).

Hopefully in the next few months we’ll get sponsoring to have per
layer control but it will be generic read/write control, not operation
oriented one.

There are OGC security proxies around that might allow more fine grained
control than what geoserver provides out of the box, there is one
from DeeGree and one from 52north. I’ve never tried to use them
but they may provide what you’re looking for.

Cheers
Andrea

7

I had a look to deegree and 52 north. I think that WAS, WSS, and WSC 1 from 52 north could be a first step to my security needs… I will test it, while DeeGree could be used as a proxy server… but as it already have lot OWS functionalities I think I could directly use it as server!

From your experience, could you list some pros and cons between Geoserver and DeeGree?

Giovanni

2008/2/2, G. Allegri <giohappy@anonymised.com>:

Thank you very much Andrea, you covered all the answers I needed. At the moment the only solution to all my needs is a proxy to manage the access poloicies to the different services.
I hope I will find sponsors to help you in developing what I was asking for :slight_smile:

Giovanni

2008/2/2, Andrea Aime <aaime@anonymised.com>:

G. Allegri ha scritto:

Thanks David.

It’s probably wise not to modify the xml files directly. The web
interface
lets you configure the information being exposed under the ‘data’
section.

I know I have to be careful in modifying the files, but I would like to
have a more fine grained then what permitted from the web interface: set
queryable layers, nillable, etc (I’m used to the METADATA tags in
Mapserver mapfiles).If it’s all controllable from the web interface… I
haven’t discovered how yet :slight_smile:
Anyway, do these files exist, or is this low-level control serialized in
non human-readable formats?

The control you’re looking for simply does not exist, code would have
to be developed in order to provide it.

About the second question, I make a scenario: I have a user that will
access wfs-t from a client (gvSIG i.e.). I want him to be autheticated
with username and password, which is mapped to ROLE_X, which is enabled
to do Insert and Update but not Delete on a specific layer (only one
beneath all the WFS layers). Is it possible to manage such a fine
grained context?

HTTP basic authentication is possible, but not control on the sigle
transaction elements. At the moment the services.properties file
allows you to control which service.method each role is allowed to
access, for example:

wfs.transaction=WFS_UPDATER

but that’s it. It applies to all layers (no per feature type control)
and does not consider transaction sub-elements.

The current security system was developed as a proof of concept
and it has been kept as is because of lack of funding (and because it’s
anyways better than the nothing 1.5.x had).

Hopefully in the next few months we’ll get sponsoring to have per
layer control but it will be generic read/write control, not operation
oriented one.

There are OGC security proxies around that might allow more fine grained
control than what geoserver provides out of the box, there is one
from DeeGree and one from 52north. I’ve never tried to use them
but they may provide what you’re looking for.

Cheers
Andrea

8

G. Allegri ha scritto:

I had a look to deegree and 52 north. I think that WAS, WSS, and WSC [1] from 52 north could be a first step to my security needs... I will test it, while DeeGree could be used as a proxy server... but as it already have lot OWS functionalities I think I could directly use it as server!
From your experience, could you list some pros and cons between Geoserver and DeeGree?

Hum, I've never used anything else besides GeoServer so I cannot really
tell. I know DeeGree supports more OGC standards, and WFS supports
complex features.
Why don't you try both of them to make up a little prototype and tell
us back how did you like each of them?

Cheers
Andrea

9

Why don’t you try both of them to make up a little prototype and tell
us back how did you like each of them?

Ok :slight_smile:

Giovanni