Re: REST 2.1.2
[EMAIL PROTECTED] wrote: Has anyone experienced a problem with a trailing front slash being added to the generated URL? I've seen it before. I can't look at my code right now, but I think it's because you have a trailing slash on a property either in struts xml (default namespace?) or in the @Namespace annotation. CodeBehind doesn't append the paths together correctly; it just assumes they can be concatenated. Now I think about it, I recall rewrting that bit of codebeind. There may be a fix in 2.1.3-SNAPSHOT, but it's possible I never committed though and just removed the unexpected /. I remember being very annoyed with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST 2.1.2
Thanks Jeromy :jumping: Have you considered the transparency of the REST URL as it relates to security and tampering? Would something like Acegi provide a solution? Also, have you considered the likliehood of a user discovering parms that can be passed and mapped onto your action? I am getting push back from folks in security about how Struts 1.X could block this behavior by including only acceptable parmaters in the ActionForm Peace, Scott Jeromy Evans - Blue Sky Minds wrote: [EMAIL PROTECTED] wrote: Has anyone experienced a problem with a trailing front slash being added to the generated URL? I've seen it before. I can't look at my code right now, but I think it's because you have a trailing slash on a property either in struts xml (default namespace?) or in the @Namespace annotation. CodeBehind doesn't append the paths together correctly; it just assumes they can be concatenated. Now I think about it, I recall rewrting that bit of codebeind. There may be a fix in 2.1.3-SNAPSHOT, but it's possible I never committed though and just removed the unexpected /. I remember being very annoyed with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/REST-2.1.2-tp19199057p19202842.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST 2.1.2
stanlick wrote: Thanks Jeromy :jumping: Have you considered the transparency of the REST URL as it relates to security and tampering? Would something like Acegi provide a solution? Also, have you considered the likliehood of a user discovering parms that can be passed and mapped onto your action? I am getting push back from folks in security about how Struts 1.X could block this behavior by including only acceptable parmaters in the ActionForm Peace, Scott Hi Scott, I'm not a REST expert, or a REST purist. I like the approach because it makes most things simpler (purists have made it seem complicated and elitist, which is stupid). Generally, I think simpler is good for security administration. If every resource (or service) has a unique URI, then filters (like Acegi) can easily control access to that resource. As soon as params are used to control behaviour it gets complicated. eg. /user/add is easier to filter than userManager.do?action=add Also by following the restful convention for http methods (gets for reads, others for modifications) you can also filter who can invoke the read, update or deletes. Role-based filters can be applied to the request (eg. only admin can post) and to action method's (only admin can invoke create()). It becomes consistent.. None of this solves the discovery of hidden params that can be passed into the action As an example, I suppose if you can create a User and a User has a hidden flag that indicates that they're an admin, and only an admin can set that flag, then there's no good way to filter than other than in the action directly or via the DI framework/java security. eg. you could prevent that method from being invoked by Subjects that don't have the admin role if the DI container allows that or a security manager is setup. I'm not an expert on Acegi either! So yeah, it may help a little because you use keep things simple and follow a convention. You don't need the REST plugin to do any of this though. It just requires an actionmapper slightly better than the default one in Struts 2.0.x. cheers, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
