Hello everyone,
I’m concluding the implementation started by aaime for the per layer security user interface.
The layers and the user security UI is ok.
At the moment I am implementing the part relating to security services, you can have a function that returns a list of methods available for a particular service?
For examples:
WFS.getAvailableMethods();
[GetFeature, Transaction, …]
Thanks,
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080
web: http://geosdi.nsdi.it
Hi Francesco,
Sorry for the late reply. But yeah, having a method somewhere for this makes sense I think. Question is about implementation of it, currently faik operations are allowed/denied based on running them through the security filters, as opposed to first getting a list of whats allowed and doing comparison.
Andrea: what do you think? How hard would providing this be? Do we need a "ServiceAccessManager" to mirror DataAccessManager?
-Justin
Francesco Izzi wrote:
Hello everyone,
I'm concluding the implementation started by aaime for the per layer security user interface.
The layers and the user security UI is ok.
At the moment I am implementing the part relating to security services, you can have a function that returns a list of methods available for a particular service?
For examples:
WFS.getAvailableMethods();
[GetFeature, Transaction, ..]
Thanks,
--
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com <mailto:francesco.izzi@anonymised.com>
skype: neofx8080
web: http://geosdi.nsdi.it
------------------------------------------------------------------------
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi Francesco,
Sorry for the late reply. But yeah, having a method somewhere for this makes sense I think. Question is about implementation of it, currently faik operations are allowed/denied based on running them through the security filters, as opposed to first getting a list of whats allowed and doing comparison.
Andrea: what do you think? How hard would providing this be? Do we need a "ServiceAccessManager" to mirror DataAccessManager?
The list is more needed for the security subsystem UI, where it
would be nice to list the operations available in a drop
down instead of a very empty text field.
I was thinking ServiceInfo could provide the list of method names?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hi Justin, Andrea,
thanks for the reply.
I looked inside the code, noted that the WFSInfo interface, declare a static enum Operation that might be useful.
Perhaps we need to do some minor modifications, but I think this is the way.
This should be developed for WMS and WCS to get an overview for the operations of the services
What you think Justin, Andrea?
Thanks,
2009/5/27 Francesco Izzi <francesco.izzi@anonymised.com>
Hello everyone,
I’m concluding the implementation started by aaime for the per layer security user interface.
The layers and the user security UI is ok.
At the moment I am implementing the part relating to security services, you can have a function that returns a list of methods available for a particular service?
For examples:
WFS.getAvailableMethods();
[GetFeature, Transaction, …]
Thanks,
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080
web: http://geosdi.nsdi.it
–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080
web: http://geosdi.nsdi.it
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Francesco,
Sorry for the late reply. But yeah, having a method somewhere for this makes sense I think. Question is about implementation of it, currently faik operations are allowed/denied based on running them through the security filters, as opposed to first getting a list of whats allowed and doing comparison.
Andrea: what do you think? How hard would providing this be? Do we need a "ServiceAccessManager" to mirror DataAccessManager?
The list is more needed for the security subsystem UI, where it
would be nice to list the operations available in a drop
down instead of a very empty text field.
I was thinking ServiceInfo could provide the list of method names?
So, if i understand juts a list of operations regardless of any security constraints? Service info... perhaps, unfortunately this would diverge a bit from the dispatching system, which is more dynamic in nature.
However, WFSInfo does something along the lines of an "Operation", an enumeration of the WFS operations. Maybe we can break out Operation as a first class object.
My only hesitation is that storing it in ServerInfo might not be the right place, since that is configuration, and a list of operations provided by a service sort of isn't. Like would we ever want it to change?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Francesco,
Sorry for the late reply. But yeah, having a method somewhere for this makes sense I think. Question is about implementation of it, currently faik operations are allowed/denied based on running them through the security filters, as opposed to first getting a list of whats allowed and doing comparison.
Andrea: what do you think? How hard would providing this be? Do we need a "ServiceAccessManager" to mirror DataAccessManager?
The list is more needed for the security subsystem UI, where it
would be nice to list the operations available in a drop
down instead of a very empty text field.
I was thinking ServiceInfo could provide the list of method names?
So, if i understand juts a list of operations regardless of any security constraints? Service info... perhaps, unfortunately this would diverge a bit from the dispatching system, which is more dynamic in nature.
However, WFSInfo does something along the lines of an "Operation", an enumeration of the WFS operations. Maybe we can break out Operation as a first class object.
My only hesitation is that storing it in ServerInfo might not be the right place, since that is configuration, and a list of operations provided by a service sort of isn't. Like would we ever want it to change?
Humm.. no, I think it's static information. We need something that
lists the operation names given a service id and an eventual version.
This information is static in nature, it depends only on the jars
you have around, but not on the configuration of GeoServer.
org.geoserver.platform.Service is instantiated one time in the app
context for each of the services we have around. Maybe that's a better
place to list operations.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Yeps, it is only for configuring the security sub system.
It’s static informations.
2009/6/1 Andrea Aime <aaime@anonymised.com…>
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Francesco,
Sorry for the late reply. But yeah, having a method somewhere for this makes sense I think. Question is about implementation of it, currently faik operations are allowed/denied based on running them through the security filters, as opposed to first getting a list of whats allowed and doing comparison.
Andrea: what do you think? How hard would providing this be? Do we need a “ServiceAccessManager” to mirror DataAccessManager?
The list is more needed for the security subsystem UI, where it
would be nice to list the operations available in a drop
down instead of a very empty text field.
I was thinking ServiceInfo could provide the list of method names?
So, if i understand juts a list of operations regardless of any security constraints? Service info… perhaps, unfortunately this would diverge a bit from the dispatching system, which is more dynamic in nature.
However, WFSInfo does something along the lines of an “Operation”, an enumeration of the WFS operations. Maybe we can break out Operation as a first class object.
My only hesitation is that storing it in ServerInfo might not be the right place, since that is configuration, and a list of operations provided by a service sort of isn’t. Like would we ever want it to change?
Humm… no, I think it’s static information. We need something that
lists the operation names given a service id and an eventual version.
This information is static in nature, it depends only on the jars
you have around, but not on the configuration of GeoServer.
org.geoserver.platform.Service is instantiated one time in the app
context for each of the services we have around. Maybe that’s a better
place to list operations.
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080
web: http://geosdi.nsdi.it
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Francesco,
Sorry for the late reply. But yeah, having a method somewhere for this makes sense I think. Question is about implementation of it, currently faik operations are allowed/denied based on running them through the security filters, as opposed to first getting a list of whats allowed and doing comparison.
Andrea: what do you think? How hard would providing this be? Do we need a "ServiceAccessManager" to mirror DataAccessManager?
The list is more needed for the security subsystem UI, where it
would be nice to list the operations available in a drop
down instead of a very empty text field.
I was thinking ServiceInfo could provide the list of method names?
So, if i understand juts a list of operations regardless of any security constraints? Service info... perhaps, unfortunately this would diverge a bit from the dispatching system, which is more dynamic in nature.
However, WFSInfo does something along the lines of an "Operation", an enumeration of the WFS operations. Maybe we can break out Operation as a first class object.
My only hesitation is that storing it in ServerInfo might not be the right place, since that is configuration, and a list of operations provided by a service sort of isn't. Like would we ever want it to change?
Humm.. no, I think it's static information. We need something that
lists the operation names given a service id and an eventual version.
This information is static in nature, it depends only on the jars
you have around, but not on the configuration of GeoServer.
org.geoserver.platform.Service is instantiated one time in the app
context for each of the services we have around. Maybe that's a better
place to list operations.
Hmm... still feels like we are trying to mix things we should not be mixing. I would just prefer a static method somewhere or something. Perhaps:
class Operation {
String getName()
}
interface WebMapService {
List<Operation> getOperations();
}
Or just list of strings if we think that will cut it. Or maybe a dedicated class:
class WMSOperations {
static List<String> getOperations()
}
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I think that a dedicated class is more usable.
2009/6/1 Justin Deoliveira <jdeolive@anonymised.com>
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Francesco,
Sorry for the late reply. But yeah, having a method somewhere for this makes sense I think. Question is about implementation of it, currently faik operations are allowed/denied based on running them through the security filters, as opposed to first getting a list of whats allowed and doing comparison.
Andrea: what do you think? How hard would providing this be? Do we need a “ServiceAccessManager” to mirror DataAccessManager?
The list is more needed for the security subsystem UI, where it
would be nice to list the operations available in a drop
down instead of a very empty text field.
I was thinking ServiceInfo could provide the list of method names?
So, if i understand juts a list of operations regardless of any security constraints? Service info… perhaps, unfortunately this would diverge a bit from the dispatching system, which is more dynamic in nature.
However, WFSInfo does something along the lines of an “Operation”, an enumeration of the WFS operations. Maybe we can break out Operation as a first class object.
My only hesitation is that storing it in ServerInfo might not be the right place, since that is configuration, and a list of operations provided by a service sort of isn’t. Like would we ever want it to change?
Humm… no, I think it’s static information. We need something that
lists the operation names given a service id and an eventual version.
This information is static in nature, it depends only on the jars
you have around, but not on the configuration of GeoServer.
org.geoserver.platform.Service is instantiated one time in the app
context for each of the services we have around. Maybe that’s a better
place to list operations.
Hmm… still feels like we are trying to mix things we should not be mixing. I would just prefer a static method somewhere or something. Perhaps:
class Operation {
String getName()
}
interface WebMapService {
List getOperations();
}
Or just list of strings if we think that will cut it. Or maybe a dedicated class:
class WMSOperations {
static List getOperations()
}
Cheers
Andrea
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080
web: http://geosdi.nsdi.it
Justin Deoliveira ha scritto:
org.geoserver.platform.Service is instantiated one time in the app
context for each of the services we have around. Maybe that's a better
place to list operations.
Hmm... still feels like we are trying to mix things we should not be mixing. I would just prefer a static method somewhere or something. Perhaps:
class Operation {
String getName()
}
interface WebMapService {
List<Operation> getOperations();
}
Or just list of strings if we think that will cut it. Or maybe a dedicated class:
class WMSOperations {
static List<String> getOperations()
}
We need something pluggable, something allowing the UI to
be populated with all the services and operations that are available.
So, it would at least have to be pluggable and searchable in
the context.
Why do you feel Service is not the right place?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
We need something pluggable, something allowing the UI to
be populated with all the services and operations that are available.
So, it would at least have to be pluggable and searchable in
the context.
Why do you feel Service is not the right place?
Well perhaps it makes sense, that class is meant to be a descriptor for the service. However it is really just a placeholder that points at the actual service with a version. With the available operations being defined by the service itself. Admittedly probably a bit over designed.
So yeah, thinking about it I would not be against adding a list of operation names to platform.Service. We will have to change the dispatcher to check this list when a request comes in, as opposed to doing a method lookup and throwing an exception when the method does not exist.
There are also a couple of things worth noting:
* The WMS "capabilities" vs "GetCapabilities" (1 operation, 2 names) will be a special case, not an issue for the dispatcher, more an issue for the UI
* For services that don't change all that much there will be a bit of duplication in the applicationContext.xml when setting up the operations
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Based on our discussion I posted a patch for this:
http://jira.codehaus.org/browse/GEOS-3108
-Justin
Justin Deoliveira wrote:
We need something pluggable, something allowing the UI to
be populated with all the services and operations that are available.
So, it would at least have to be pluggable and searchable in
the context.
Why do you feel Service is not the right place?
Well perhaps it makes sense, that class is meant to be a descriptor for the service. However it is really just a placeholder that points at the actual service with a version. With the available operations being defined by the service itself. Admittedly probably a bit over designed.
So yeah, thinking about it I would not be against adding a list of operation names to platform.Service. We will have to change the dispatcher to check this list when a request comes in, as opposed to doing a method lookup and throwing an exception when the method does not exist.
There are also a couple of things worth noting:
* The WMS "capabilities" vs "GetCapabilities" (1 operation, 2 names) will be a special case, not an issue for the dispatcher, more an issue for the UI
* For services that don't change all that much there will be a bit of duplication in the applicationContext.xml when setting up the operations
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.