[Geoserver-devel] [Geotools-devel] ava.lang.ClassCastException: org.geoserver.security.decorators.SecuredIterator

GeoServer GeoServer Developer
1

Hi Andrea , I am unsure by what you mean by passing down the interface.

Would you be able to be more specific? I am unsure how the code works as i was not able to replicate the issue on my local machine J

I tried the following

return (FeatureIterator) SecuredObjects.secure((FeatureIterator)delegate.features(), policy);

FeatureCollection fc=(FeatureCollection)SecuredObjects.secure(delegate.features(), policy);

return fc.features();

both to no avail.

I am just taking shots in the dark. Once again thanks :smiley:

IMappingFeatureIterator extends Iterator, FeatureIterator

This might be the cause but I am unsure why it would cause an error casting to FeatureIterator.

From: andrea.aime@anonymised.com [mailto:andrea.aime@…403…] On Behalf Of Andrea Aime
Sent: Monday, 11 April 2011 11:58 PM
To: Justin Deoliveira
Cc: Tey, Victor (CESRE, Kensington); Geotools-Devel list
Subject: Re: [Geotools-devel] ava.lang.ClassCastException: org.geoserver.security.decorators.SecuredIterator

On Mon, Apr 11, 2011 at 4:39 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Victor,

I believe this is a more specifically a geoserver issue… you should probably move the conversation there. As for the fix I still think modifying the SecuredObject* interfaces in geoserver to explicitly pass down the interface is the most robust option. But that is something for discussion on geoserver-devel.

Passing down the interface might be an option, another one could be a security wrapper that implements

both interfaces, so that we don’t even have to decide

Cheers

Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

2

What we mean is modifying SecureObjects.secure to take an additional class parameter. So that when a reader implements both FeatureIterator and Iterator the calling code is explicit as to what wrapper it wants. Ie.

SecureObjects.secure(it, policy)

Goes to:

SecureObjects.secure(it, policy, FeatureIterator.class)

That way the SecuredObjectFactory implementations don’t have to guess as to what interface the client wants to wrap. Look at DefaultSecuredDataFactory to see what I mean.

However, as Andrea stated a less invasive solution would just be to modify SecuredIterator so that it implements both Iterator and FeatureIterator. And then we would remove SecuredFeatureIterator. And i guess the same would go for SimpleFeatureIterator as well.

All in all the second solution is going to be the most straight forward so it’s probably your best bet.

Hope that helps.

-Justin

On Tue, Apr 12, 2011 at 3:46 AM, <Victor.Tey@anonymised.com.> wrote:

Hi Andrea , I am unsure by what you mean by passing down the interface.

Would you be able to be more specific? I am unsure how the code works as i was not able to replicate the issue on my local machine J

I tried the following

return (FeatureIterator) SecuredObjects.secure((FeatureIterator)delegate.features(), policy);

FeatureCollection fc=(FeatureCollection)SecuredObjects.secure(delegate.features(), policy);

return fc.features();

both to no avail.

I am just taking shots in the dark. Once again thanks :smiley:

IMappingFeatureIterator extends Iterator, FeatureIterator

This might be the cause but I am unsure why it would cause an error casting to FeatureIterator.

From: andrea.aime@anonymised.com [mailto:andrea.aime@anonymised.com] On Behalf Of Andrea Aime
Sent: Monday, 11 April 2011 11:58 PM
To: Justin Deoliveira
Cc: Tey, Victor (CESRE, Kensington); Geotools-Devel list
Subject: Re: [Geotools-devel] ava.lang.ClassCastException: org.geoserver.security.decorators.SecuredIterator

On Mon, Apr 11, 2011 at 4:39 PM, Justin Deoliveira <jdeolive@anonymised.com1…> wrote:

Hi Victor,

I believe this is a more specifically a geoserver issue… you should probably move the conversation there. As for the fix I still think modifying the SecuredObject* interfaces in geoserver to explicitly pass down the interface is the most robust option. But that is something for discussion on geoserver-devel.

Passing down the interface might be an option, another one could be a security wrapper that implements

both interfaces, so that we don’t even have to decide

Cheers

Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

On Tue, Apr 12, 2011 at 11:46 AM, <Victor.Tey@anonymised.com> wrote:

IMappingFeatureIterator extends Iterator<Feature>, FeatureIterator<Feature>

This might be the cause but I am unsure why it would cause an error casting
to FeatureIterator.

The issue is indeed caused by your class implementing those two interfaces
at the same time.

The current security wrapping code thinks it's possible to know if something
is an iterator _or_ a feature iterator by "instanceof" inspection on the
object that has to be wrapped.
Once wrapped the object will only implement one of the two interfaces to
the caller.

Unfortunately due to the fact you're implementing both we're guessing wrong
50% of the time.

Justin suggestion goes along the lines of "don't get, have someone tell you".
Along this line the SecuredObjects.secure(...) caller should also
provide a param
telling you what interface is the desired one.
This would work and it would be probably clearn,
but it would require quite a bit of changes around the code

My suggestion was more hacky, create a new security wrappers that also
implements
both interfaces, and if you find an object that implement both
iterators use that
specific wrapper.

Hope this helps

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

4

Thanks for clarifying.

I have attached a patch. I have not create a unit test yet but I would like to confirm the approach J

Would you be able to give your opinion and I will proceed to add unit test to it. Thanks again.

From: Justin Deoliveira [mailto:jdeolive@anonymised.com…]
Sent: Tuesday, 12 April 2011 10:20 PM
To: Tey, Victor (CESRE, Kensington)
Cc: andrea.aime@anonymised.com; geoserver-devel@lists.sourceforge.net
Subject: Re: [Geotools-devel] ava.lang.ClassCastException: org.geoserver.security.decorators.SecuredIterator

What we mean is modifying SecureObjects.secure to take an additional class parameter. So that when a reader implements both FeatureIterator and Iterator the calling code is explicit as to what wrapper it wants. Ie.

SecureObjects.secure(it, policy)

Goes to:

SecureObjects.secure(it, policy, FeatureIterator.class)

That way the SecuredObjectFactory implementations don’t have to guess as to what interface the client wants to wrap. Look at DefaultSecuredDataFactory to see what I mean.

However, as Andrea stated a less invasive solution would just be to modify SecuredIterator so that it implements both Iterator and FeatureIterator. And then we would remove SecuredFeatureIterator. And i guess the same would go for SimpleFeatureIterator as well.

All in all the second solution is going to be the most straight forward so it’s probably your best bet.

Hope that helps.

-Justin

On Tue, Apr 12, 2011 at 3:46 AM, Victor.Tey@anonymised.com wrote:

Hi Andrea , I am unsure by what you mean by passing down the interface.

Would you be able to be more specific? I am unsure how the code works as i was not able to replicate the issue on my local machine J

I tried the following

return (FeatureIterator) SecuredObjects.secure((FeatureIterator)delegate.features(), policy);

FeatureCollection fc=(FeatureCollection)SecuredObjects.secure(delegate.features(), policy);

return fc.features();

both to no avail.

I am just taking shots in the dark. Once again thanks :smiley:

IMappingFeatureIterator extends Iterator, FeatureIterator

This might be the cause but I am unsure why it would cause an error casting to FeatureIterator.

From: andrea.aime@anonymised.com…403… [mailto:andrea.aime@anonymised.com] On Behalf Of Andrea Aime
Sent: Monday, 11 April 2011 11:58 PM
To: Justin Deoliveira
Cc: Tey, Victor (CESRE, Kensington); Geotools-Devel list
Subject: Re: [Geotools-devel] ava.lang.ClassCastException: org.geoserver.security.decorators.SecuredIterator

On Mon, Apr 11, 2011 at 4:39 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Victor,

I believe this is a more specifically a geoserver issue… you should probably move the conversation there. As for the fix I still think modifying the SecuredObject* interfaces in geoserver to explicitly pass down the interface is the most robust option. But that is something for discussion on geoserver-devel.

Passing down the interface might be an option, another one could be a security wrapper that implements

both interfaces, so that we don’t even have to decide

Cheers

Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira

OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

(attachments)

GEOS-4488.patch (3.76 KB)

5

Hi Victor,

The first hunk looks wrong to me and will lead to a class cast exception:

} else if (SimpleFeatureIterator.class.isAssignableFrom(clazz)) {
return new SecuredSimpleFeatureIterator((SimpleFeatureIterator) object);
} else if (FeatureIterator.class.isAssignableFrom(clazz)) {

  • return new SecuredFeatureIterator((FeatureIterator) object);
  • //return new SecuredFeatureIterator((FeatureIterator) object);
  • return new SecuredIterator((Iterator) object, policy);
    }

Checking if the object being wrapped is a FeatureIterator and then casting i to iterator. Other then that the patch looks ok.

On Fri, Apr 15, 2011 at 3:36 AM, Victor.Tey@anonymised.com wrote:

Thanks for clarifying.

I have attached a patch. I have not create a unit test yet but I would like to confirm the approach J

Would you be able to give your opinion and I will proceed to add unit test to it. Thanks again.

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Tuesday, 12 April 2011 10:20 PM
To: Tey, Victor (CESRE, Kensington)
Cc: andrea.aime@anonymised.com; geoserver-devel@anonymised.come.net
Subject: Re: [Geotools-devel] ava.lang.ClassCastException: org.geoserver.security.decorators.SecuredIterator

What we mean is modifying SecureObjects.secure to take an additional class parameter. So that when a reader implements both FeatureIterator and Iterator the calling code is explicit as to what wrapper it wants. Ie.

SecureObjects.secure(it, policy)

Goes to:

SecureObjects.secure(it, policy, FeatureIterator.class)

That way the SecuredObjectFactory implementations don’t have to guess as to what interface the client wants to wrap. Look at DefaultSecuredDataFactory to see what I mean.

However, as Andrea stated a less invasive solution would just be to modify SecuredIterator so that it implements both Iterator and FeatureIterator. And then we would remove SecuredFeatureIterator. And i guess the same would go for SimpleFeatureIterator as well.

All in all the second solution is going to be the most straight forward so it’s probably your best bet.

Hope that helps.

-Justin

On Tue, Apr 12, 2011 at 3:46 AM, Victor.Tey@anonymised.com wrote:

Hi Andrea , I am unsure by what you mean by passing down the interface.

Would you be able to be more specific? I am unsure how the code works as i was not able to replicate the issue on my local machine J

I tried the following

return (FeatureIterator) SecuredObjects.secure((FeatureIterator)delegate.features(), policy);

FeatureCollection fc=(FeatureCollection)SecuredObjects.secure(delegate.features(), policy);

return fc.features();

both to no avail.

I am just taking shots in the dark. Once again thanks :smiley:

IMappingFeatureIterator extends Iterator, FeatureIterator

This might be the cause but I am unsure why it would cause an error casting to FeatureIterator.

From: andrea.aime@anonymised.com [mailto:andrea.aime@anonymised.com] On Behalf Of Andrea Aime
Sent: Monday, 11 April 2011 11:58 PM
To: Justin Deoliveira
Cc: Tey, Victor (CESRE, Kensington); Geotools-Devel list
Subject: Re: [Geotools-devel] ava.lang.ClassCastException: org.geoserver.security.decorators.SecuredIterator

On Mon, Apr 11, 2011 at 4:39 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Victor,

I believe this is a more specifically a geoserver issue… you should probably move the conversation there. As for the fix I still think modifying the SecuredObject* interfaces in geoserver to explicitly pass down the interface is the most robust option. But that is something for discussion on geoserver-devel.

Passing down the interface might be an option, another one could be a security wrapper that implements

both interfaces, so that we don’t even have to decide

Cheers

Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira

OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.