Looks like it just isn't possible to have SetEnv affect the environment of the access handler. This is because the fixup phase in Apache where SetEnv directives are evaluated and incorporated into the per request environment, is done after the authnz handlers are run. The only option would be to have any special path required read from some separate system file from the access script when first loaded.
Graham > On 6 Nov 2019, at 11:37 am, Jared Greenwald <[email protected]> wrote: > > Here's my conf file. It's being set at the VH level. I was able to work > around it by hard coding the conf file name in my code, but that's obviously > not ideal for deploying to dev/test/prod environments and having to change > the code each time I should say that aside from this setenv quirk, the > code/conf seem to be working as I intended... > > Listen myip:myport > > LogFormat format-goodness custom-format > > WSGIRestrictEmbedded On > WSGIPythonPath /my/python/path > <VirtualHost myip:myport> > ServerName myserver.com > ErrorLog "|$/usr/sbin/rotatelogs /var/log/httpd/${HOSTNAME}_error_log.%y-%W > 86400 -360" > LogLevel debug > CustomLog "|$/usr/sbin/rotatelogs > /var/log/httpd/${HOSTNAME}_access_log.%y-%W 86400 -360" custom-format > > SetEnv CONFIG_FILE myconfig.conf > > Options Indexes FollowSymLinks > Alias /URL/PATH /my/file/dir > Alias /URL/PATH2 /my/file/dir > <Directory /my/file/dir> > Require all granted > WSGIAccessScript /my/file/dir/myscript.py > </Directory> > > WSGIDaemonProcess myname processes=2 threads=15 display-name=%{GROUP} > python-path='/my/file/dir/' processes=1 threads=5 > WSGIProcessGroup mypgroup > WSGIScriptAliasMatch ^/(API/PATH$|api/path$) /my/file/dir/myscript.py > <Directory /my/file/dir> > Require all granted > </Directory> > </VirtualHost> > > > On Tuesday, November 5, 2019 at 6:36:16 PM UTC-5, Graham Dumpleton wrote: > The access check phase in Apache is done quite early, before it has resolved > a URL to a specific handler. Any SetEnv values inside of Location or > Directory directives wouldn't therefore be available. Anything defined at > VirtualHost scope, or outside of the VirtualHost should be though. > > At what scope are your SetEnv directives? > >> On 6 Nov 2019, at 7:18 am, Jared Greenwald <[email protected] <>> wrote: >> >> Ok, I seem to be able to get into my allow_access now by disabling some >> other conf.d config files that were installed by default as well as adding >> "Require all granted" to the directory stanza. Now, my issue is that I >> can't seem to get access to any of the SetEnv variables I set in my apache >> config file. I had been using a CONFIG_FILE variable to load the >> application config file for my python code which has some various config >> variables, but for some reason this variable isn't being loaded into the >> environment that's being passed to allow_access. It's set directly above >> the directory stanza where I setup the WSGIAccessScript. I know it's being >> used further down in the config as the main API section of my config is >> using it just fine. I understand that the allow_access environment is >> somewhat restricted in what it allows but is there any way to get access to >> an environment variable that's set in the apache config like this or is >> there a better way? >> >> On Monday, October 28, 2019 at 9:51:43 PM UTC-4, Graham Dumpleton wrote: >> What I might suggest is use 'pip install mod_wsgi' into a virtual >> environment, and then use mod_wsgi-express to test out the configuration for >> how it generates things, to see if it works on your Apache version. >> >> You can use: >> >> mod_wsgi-express start-server --access-script /some/path/access.wsgi >> >> If that works, we can look at the configuration I generate with that to work >> out what may be different with your setup. >> >>> On 29 Oct 2019, at 6:42 am, Jared Greenwald <[email protected] <>> wrote: >>> >>> What would you think would be the most minimal set of modules to enable for >>> both python to work and for basic file downloads with auth? Is there an >>> easy-ish way to debug other than turning every module off and then enabling >>> them one-by-one until it all works? >>> >>> On Friday, October 25, 2019 at 9:04:16 PM UTC-4, Graham Dumpleton wrote: >>> You appear to have the correct modules loaded. They being: >>> >>> authz_core_module >>> authz_host_module >>> >>> The thing with access controls is that they are processed sequentially, so >>> if one matches as true before gets to WSGIScriptAlias, that will take >>> priority. >>> >>> So if you already have another directive earlier which matches, you will >>> always be allowed in. >>> >>> For example any of the Require directives which pertain to the access phase. >>> >>> You also have: >>> >>> access_compat_module >>> >>> so you have to watch out for Allow directives as well. >>> >>> So I would check through your config file look for any other directives >>> which allow by host in some way. >>> >>> Graham >>> >>>> On 26 Oct 2019, at 11:56 am, Jared Greenwald <greenwa...@ <>gmail.com >>>> <http://gmail.com/>> wrote: >>>> >>>> was that the right info? >>>> >>>> On Wednesday, October 23, 2019 at 7:37:48 AM UTC-4, Jared Greenwald wrote: >>>> It's a pretty stock install. I haven't really enabled/disabled anything >>>> other than installing mod_wsgi and getting the main python stack setup. >>>> >From httpd -M... >>>> >>>> Loaded Modules: >>>> core_module (static) >>>> so_module (static) >>>> http_module (static) >>>> access_compat_module (shared) >>>> actions_module (shared) >>>> alias_module (shared) >>>> allowmethods_module (shared) >>>> auth_basic_module (shared) >>>> auth_digest_module (shared) >>>> authn_anon_module (shared) >>>> authn_core_module (shared) >>>> authn_dbd_module (shared) >>>> authn_dbm_module (shared) >>>> authn_file_module (shared) >>>> authn_socache_module (shared) >>>> authz_core_module (shared) >>>> authz_dbd_module (shared) >>>> authz_dbm_module (shared) >>>> authz_groupfile_module (shared) >>>> authz_host_module (shared) >>>> authz_owner_module (shared) >>>> authz_user_module (shared) >>>> autoindex_module (shared) >>>> cache_module (shared) >>>> cache_disk_module (shared) >>>> data_module (shared) >>>> dbd_module (shared) >>>> deflate_module (shared) >>>> dir_module (shared) >>>> dumpio_module (shared) >>>> echo_module (shared) >>>> env_module (shared) >>>> expires_module (shared) >>>> ext_filter_module (shared) >>>> filter_module (shared) >>>> headers_module (shared) >>>> include_module (shared) >>>> info_module (shared) >>>> log_config_module (shared) >>>> logio_module (shared) >>>> mime_magic_module (shared) >>>> mime_module (shared) >>>> negotiation_module (shared) >>>> remoteip_module (shared) >>>> reqtimeout_module (shared) >>>> rewrite_module (shared) >>>> setenvif_module (shared) >>>> slotmem_plain_module (shared) >>>> slotmem_shm_module (shared) >>>> socache_dbm_module (shared) >>>> socache_memcache_module (shared) >>>> socache_shmcb_module (shared) >>>> status_module (shared) >>>> substitute_module (shared) >>>> suexec_module (shared) >>>> unique_id_module (shared) >>>> unixd_module (shared) >>>> userdir_module (shared) >>>> version_module (shared) >>>> vhost_alias_module (shared) >>>> dav_module (shared) >>>> dav_fs_module (shared) >>>> dav_lock_module (shared) >>>> lua_module (shared) >>>> mpm_event_module (shared) >>>> proxy_module (shared) >>>> lbmethod_bybusyness_module (shared) >>>> lbmethod_byrequests_module (shared) >>>> lbmethod_bytraffic_module (shared) >>>> lbmethod_heartbeat_module (shared) >>>> proxy_ajp_module (shared) >>>> proxy_balancer_module (shared) >>>> proxy_connect_module (shared) >>>> proxy_express_module (shared) >>>> proxy_fcgi_module (shared) >>>> proxy_fdpass_module (shared) >>>> proxy_ftp_module (shared) >>>> proxy_http_module (shared) >>>> proxy_scgi_module (shared) >>>> proxy_wstunnel_module (shared) >>>> systemd_module (shared) >>>> cgid_module (shared) >>>> wsgi_module (shared) >>>> >>>> On Tuesday, October 22, 2019 at 10:32:42 PM UTC-4, Graham Dumpleton wrote: >>>> What mod_auth?? modules have you enabled in Apache? >>>> >>>>> On 23 Oct 2019, at 1:28 pm, Jared Greenwald <greenwa...@ <>gmail.com >>>>> <http://gmail.com/>> wrote: >>>>> >>>>> As I mentioned in a previous post, I'm attempting to convert an >>>>> application from mod_python to mod_wsgi. One thing I need to replace is >>>>> authenticated downloads via apache. Basically GET requests with headers >>>>> set that can be picked out by python code and used to check against a >>>>> database or other means. The checking code already exists, but it's just >>>>> the apache->python plumbing that's needed. It seems like >>>>> WSGIAccessScript would be the directive to use for this, but I'm not >>>>> getting any of the results I expect. I have essentially the following in >>>>> my apache config... >>>>> >>>>> Options Indexes FollowSymLinks >>>>> Alias /my/download/path /my/local/download/dir >>>>> <Directory /my/local/download/dir> >>>>> WSGIAccessScript /my/script/dir/somescript.py >>>>> </Directory> >>>>> >>>>> SetEnv CONFIG_FILE myconfigfile.conf >>>>> WSGIDaemonProcess my-process processes=2 threads=15 >>>>> display-name=%{GROUP} python-path='/my/script/dir/' processes=1 threads=5 >>>>> WSGIProcessGroup my-process-group >>>>> WSGIScriptAliasMatch ^/(apiurl1|apiurl2$) /my/script/dir/somescript.py >>>>> <Directory /my/script/dir> >>>>> Require all granted >>>>> </Directory> >>>>> >>>>> The APIs served by the WSGIScriptAlias script directive seem to work just >>>>> fine. I stubbed out the allow_access function to just return false to >>>>> test out that it was working (to deny all) but when I attempt to download >>>>> http://myserver.com/my/download/path/myfile >>>>> <http://myserver.com/my/download/path/myfile>, I get the file just fine >>>>> without an error. I'm not even sure if the allow_access call is being >>>>> made or not. Am I missing something? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "modwsgi" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to mod...@ <>googlegroups.com <http://googlegroups.com/>. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/modwsgi/5d2c62d8-775f-41a0-99cf-a2ec0658dac5%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/modwsgi/5d2c62d8-775f-41a0-99cf-a2ec0658dac5%40googlegroups.com?utm_medium=email&utm_source=footer>. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "modwsgi" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to mod...@ <>googlegroups.com <http://googlegroups.com/>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/modwsgi/971d99c2-52f4-443d-8130-872045c645c3%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/modwsgi/971d99c2-52f4-443d-8130-872045c645c3%40googlegroups.com?utm_medium=email&utm_source=footer>. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected] <>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/modwsgi/07343b6d-74a2-4370-9ca2-26163680e10b%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/modwsgi/07343b6d-74a2-4370-9ca2-26163680e10b%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/modwsgi/094c8fbb-a472-46f1-beb6-678dab52760d%40googlegroups.com >> >> <https://groups.google.com/d/msgid/modwsgi/094c8fbb-a472-46f1-beb6-678dab52760d%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/0d1f515f-907a-4c64-92cb-1eeceb059828%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/0d1f515f-907a-4c64-92cb-1eeceb059828%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/3A109330-7348-4034-8B02-56C87E9601C9%40gmail.com.
