Feature request #20992

Specify project file through a FastCGI param

Added by Éric Lemoine over 1 year ago. Updated over 1 year ago.

Status:Closed
Priority:Normal
Assignee:Éric Lemoine
Category:QGIS Server
Pull Request or Patch supplied:No Resolution:worksforme
Easy fix?:Yes Copied to github as #:28811

Description

QGIS Server doesn't currently support specifying the QGIS project file through a FastCGI parameter (using NGINX's fastcgi_param for example). This feature request suggests adding that capability.

Currently there are two ways to specify the project file:

  1. by setting the QGIS_PROJECT_FILE env var at qgis_mapserv.fcgi execution time,
  2. by setting the MAP query param in the request URL.

What people often want to do is associate URL paths to QGIS projects. For example they want to associate /water to water.qgs, and /crop to crop.qgs. So for that they want to set the project file in the route definition of the web server config. For example with NGINX:

location /water {
    include fastcgi_params;
    fastcgi_pass   unix:/var/run/fcgiwrap.socket;
    fastcgi_param  QGIS_PROJECT_FILE /file/system/path/to/water.qgs;
}

But this doesn't work in the general case. It works when fcgiwrap is used. But fcgiwrap is a special case, because, as documented in the QGIS Server docs, fcgiwrap creates a new QGIS Server process on each request, and it translates all the FastCGI parameters into environment variables for the new process. When using spawn-fcgi or Systemd directly setting QGIS_PROJECT_FILE as a FastCGI param will have no effect at all.

So this feature request suggests adding a third way to specify the project file: by setting the QGIS_PROJECT_FILE FastCGI parameter. The logic will be this:

  1. if the QGIS_PROJECT_FILE env var is set use project file it specifies
  2. else, if the QGIS_PROJECT_FILE FastCGI param is set use the project file it specifies
  3. else, if the MAP query parameter is set use the project file it specifies
  4. else, fail

Today step #2 doesn't exist.

I have a branch implementing this, which I will turn into a Pull Request.

History

#1 Updated by Alessandro Pasotti over 1 year ago

I don't see the necessity this feature: the standard way of doing such a manipulation is using a rewrite module (mod_rewite or nginx internal rewrite directive) to rewrite the MAP argument of the QUERY_STRING.

#2 Updated by Giovanni Manghi over 1 year ago

  • Status changed from Open to Feedback

#3 Updated by Éric Lemoine over 1 year ago

Alessandro, good point. There may be simpler solutions indeed. I'll have a closer look. In any case this suggests for better docs.

#4 Updated by Alessandro Pasotti over 1 year ago

Éric, I'm not sure we should document that kind of things: the URL rewrite procedure belongs to the web server domain and has been standard practice for decades.

I think we should focus our limited documentation efforts to document what is really specific to QGIS server (like for instance the vendor parameters, the caching mechanisms, the plugins etc.).

IMO this topic could be a good candidate for a tutorial or a blog post.

#5 Updated by Éric Lemoine over 1 year ago

Alessandro, based on your comments I've tried using the following in the NGINX config:

location /water {
    fastcgi_param QUERY_STRING $query_string&MAP=/data/water.qgs;
    include fastcgi_params;
    fastcgi_pass   unix:/var/run/fcgiwrap.socket;
}

So adding MAP=/data/water.qgs to the query string on each request.

But if I do that I will end up with OnlineResource's in the Capabilities document that include the MAP parameter (e.g. /water?MAP=/data/water.qgs), which I don't want.

What do you think?

Regarding the docs I don't fully agree, but this is a separate discussion.

#7 Updated by Éric Lemoine over 1 year ago

Maybe you are hitting: https://github.com/qgis/QGIS/pull/8830

Yes, indeed. So the following NGINX config does the job for my case:

location /water {
    fastcgi_param QUERY_STRING $query_string&MAP=/data/water.qgs;
    include fastcgi_params;
    fastcgi_pass   unix:/var/run/fcgiwrap.socket;
}

Thanks for the discussion Alessandro!

I am closing this issue for now.

#8 Updated by Éric Lemoine over 1 year ago

Or someone does it for me as I don't seem to have the permission to do it :)

#9 Updated by Jürgen Fischer over 1 year ago

  • Resolution set to worksforme
  • Status changed from Feedback to Closed

Also available in: Atom PDF