Hello, Samuel <samuel.trego...@nereide.fr> writes:
> Moreover if you don't use a service event in your request map you can > access whatever url parameter you want, so I cannot see why service > event is so particular in this regards. Indeed if the issue is about forbidding URI parameters because of security reason, this check should be hardcoded in the RequestHandler not by individual EventHandler implementations. Otherwise this is just absurd because every administrator/integrator can then implement an ad-hoc Java/Groovy event handler invoking a service without being warned about a “known” security issue. Jacques Le Roux <jacques.le.r...@les7arts.com> writes: > I agree that it's an overkill. I guess because services give you more > power so need to be more secure. > > The same person that, like you, doubted about the reason of > checkSecureParameter() spoke also about the possibility to "inject > stuff using parameters" > > Here is what he said (actually this was reported to me by a 3rd person > but I much trust them both) > > "The other case I reported has more to do with people being able to > inject stuff using parameters. Because they are not always > escaped. In particular the case for the VIEW_INDEX parameter and > alike view_size, view_index often in combination with screen > widget but not only" > > Anyway what would you suggest? You know you can set > service.http.parameters.require.encrypted=N, is that not enough? I am not convinced by the explanation or by the non-solution of keeping an option with confusing security impacts. IMO for the sake of both simplicity and sanity we should just nuke the option and accept URI parameters unconditionally. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
