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, <[email protected]> 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:[email protected]]
> *Sent:* Tuesday, 12 April 2011 10:20 PM
> *To:* Tey, Victor (CESRE, Kensington)
> *Cc:* [email protected]; [email protected]
> *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, <[email protected]> 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 :D
>
>
>
> IMappingFeatureIterator extends Iterator<Feature>, FeatureIterator<Feature>
>
>
>
> This might be the cause but I am unsure why it would cause an error casting
> to FeatureIterator.
>
>
>
>
>
>
>
> *From:* [email protected] [mailto:[email protected]] *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 <[email protected]>
> 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.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
