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] > <javascript:>> 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 <[email protected]> >> 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 <[email protected]> >>>> 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, 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 [email protected]. >>>> 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 [email protected]. >> 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] <javascript:>. > 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.
