[QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?

[Alessandro Pasotti]

On Wed, Apr 10, 2019 at 11:37 PM David Marteau <dmarteau at 3liz.com> wrote:

>
> > Le 10 avr. 2019 à 23:21, pblottiere <paul.blottiere at oslandia.com> a
> écrit :
> >
> > Hi David,
> >
> >
> >> If you try:
> >>
> >> request.setParameter('FOOBAR','foobar')
> >>
> >> then
> >>
> >> request.parameter('FOOBAR')
> >>
> >> then you get an empty string,
> >>> Even if I add  an 'allowed' parameter by hand:
> >>>
> >>>> request.setParameter('FI_POINT_TOLERANCE','25')
> >
> > Actually, QgsServerRequest and QgsServerParameters are high level
> > classes which are not aware of valid parameters defined in services. For
> > example, FI_POINT_TOLERANCE is a valid parameter in WMS service, and
> > defined within the WMS module. But it's totally encapsulated within the
> > module (a shared library so), and considered as unknown from
> > QgsServerParameters. The only valid parameters from the
> > QgsServerParameters point of view are those which are common for all
> > services (WMS, WFS, and so on) like SERVICE, VERSION, REQUEST, ...
> >
> > If you want to retrieve the full query from the request without any
> > filter on valid parameters, you may use request.url(). However, I think
> > we could probably add a fallback on the `parameter()` method to return
> > invalid parameters too. I'll do a PR tomorrow and I'll ping you to check
> > if the behaviour suits you.
> >
> >
>
> Yes, this is what I was thinking about Looking at the code: maybe adding a
> lookup to the 'unmanaged' parameters if the code is not found should
> restore the symmetry setParameter/parameter.
>
> I'm standing from the python plugin's point of view - services and
> filters: plugins are expecting some behavior when setting/getting
> parameters. If a plugin override a parameter it can only doing it using the
> requestHandler which is aware
> only of the  base QgsServerParameters owned by the  QgsServerRequest
> instance, so they should be able to set/get parameters in a transparent way.
>
> Regards
>
> David.
>
>
Hi David,

that makes sense, I agree completely, it's odd I didn't catch this issue
before during one of my tests with plugins, I often use parameters to pass
information around within plugins.

May I suggest that we add a test case to protect the changes when done?

Thanks!



> > Regards,
> >
> > Paul
> >
> >
> > On 4/10/19 10:37 PM, David Marteau wrote:
> >> To add some precision:
> >>
> >> Even if I add  an 'allowed' parameter by hand:
> >>
> >>> request.setParameter('FI_POINT_TOLERANCE','25')
> >> then
> >>
> >>> request.parameter('FI_POINT_TOLERANCE')
> >> return an empty string
> >>
> >>> Le 10 avr. 2019 à 19:46, David Marteau <dmarteau at 3liz.com> a écrit :
> >>>
> >>>
> >>> Hi devs,
> >>>
> >>> I found a strange and seemingly inconsistent behavior when accessing
> QgsServerRequest parameters:
> >>>
> >>> If you try:
> >>>
> >>> request.setParameter('FOOBAR','foobar')
> >>>
> >>> then
> >>>
> >>> request.parameter('FOOBAR')
> >>>
> >>> then you get an empty string,
> >>>
> >>> If you call
> >>>
> >>> request.parameters()
> >>>
> >>> Then your get a dictionary with all the values previously set.
> >>>
> >>> At first glance it seems that request.setParameter enforce use of a
> limited set of keys (SERVICE…..
> >>>
> >>> This does not seem very consistent with the fact parameter() should
> return any value previously set with setParameter and also the fact that
> >>> request.parameters()  return all previously defined  parameters
> key/values .
> >>>
> >>> Furthemore this may be  problematic with plugins that define services
> in python and thus may define any other set of allowed parameters.
> >>>
> >>> Should I open an issue ?
> >>>
> >>> David
> >
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190411/a21e3ac4/attachment.html>