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]
> <javascript:>> 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 <[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].
>> 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] <javascript:>.
> 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/modwsgi/0d1f515f-907a-4c64-92cb-1eeceb059828%40googlegroups.com.
