I'm trying the following patch against mod_wsgi 4.8 (since I am outside the 
design of mod_wsgi). I can integrate this later with a custom Apache 
directive (for now I will just continue to use WSGIAccessScript).

15595c15595

<                         allow = AUTH_DENIED;

---

>                         allow = -1;

15599,15614c15599

<                             allow = AUTH_GRANTED;

<                     }

<                     else if (result == Py_False) {

<                         allow = AUTH_DENIED;

<                     }

<                     else if (PyUnicode_Check(result)) {

<                         PyObject *str = NULL;

< 

<                         str = PyUnicode_AsUTF8String(result);

< 

<                         if (str) {

<                             adapter->r->user = 
apr_pstrdup(adapter->r->pool,

<                                     PyString_AsString(str));

< 

<                             allow = AUTH_GRANTED;

<                         }

---

>                             allow = 1;


On Tuesday, June 15, 2021 at 12:25:35 PM UTC-7 Neil Verkland wrote:

> The most promising solution is creating a WSGIAccessScript in Python (that 
> checks for valid cookies) except, I need to 'set' the username at the end 
> of the successful authentication. Is there a mechanism 
> with WSGIAccessScript to export variables back to apache (set user or 
> REMOTE_USER or any other variable)? If Access is denied by the script, I 
> can 302 the user to an independent login form that will then create their 
> encrypted cookie.
>
> On Tuesday, June 15, 2021 at 11:34:14 AM UTC-7 Neil Verkland wrote:
>
>> Today I tried sending ‘barkbark’ as the password from the client. There 
>> was no behavior change. The login form is still continuously presented to 
>> the user.
>>
>> Sent from my iPhone
>>
>> On Jun 14, 2021, at 9:00 PM, Neil Verkland <[email protected]> wrote:
>>
>> Today’s tests the client did not send ‘bark bark’. That will be the 
>> definitive test (tomorrow) that I spoke of.
>>
>>
>>
>> Sent from my iPhone
>>
>> On Jun 14, 2021, at 8:48 PM, Graham Dumpleton <[email protected]> 
>> wrote:
>>
>> If mod_perl has a working solution it is possibly because they are 
>> rolling their own authentication handler from scratch, where as mod_wsgi 
>> hooks into the authentication provider hooks of Apache, which has more 
>> rigid rules around how the interfacing works.
>>
>> Anyway, I was wrong that you weren't providing a password, but you are 
>> providing a fixed passed:
>>
>>     ustr = f'{uname}:barkbark:{realm}'
>>
>> Is the client definitely sending a password of "barkbark"?
>>
>> If it is, then it possibly should work.
>>
>> Graham
>>
>> On 15 Jun 2021, at 12:21 pm, Neil Verkland <[email protected]> wrote:
>>
>> It’s an interesting possibility. I’ll mess with the code (with that in 
>> mind) and see if I make any progress. If I do find that the has has to 
>> match on that Apache is putting together then I’ll have to switch to 
>> mod-Perl where I already have a working solution.
>>
>> I was hoping to move to mod-wsgi so all layers would be Python based (all 
>> the cgi’s are Python based).
>>
>> Sent from my iPhone
>>
>> On Jun 14, 2021, at 6:52 PM, Graham Dumpleton <[email protected]> 
>> wrote:
>>
>> I don't remember exactly how digest auth works, but it worries me you 
>> generating a hash as return value which doesn't have a password as input. I 
>> suspect that Apache or something is going to compare that hash with one 
>> generated from what the browser submitted and they need to match. Can't see 
>> how they would match with what you are doing.
>>
>> Graham
>>
>> On 15 Jun 2021, at 11:38 am, Neil Verkland <[email protected]> wrote:
>>
>>
>> I'm attempting to use mod_wsgi for Authen (Digest) only. Once Authen is 
>> complete, all other scripts in the Apache directories will be served as 
>> CGI's or static files (or mod_proxy will pass the request on).
>>
>> At present (with the configs below) the WSGI (Digest) authentication 
>> script is being executed and is returning a hex-digest of an md5 sum of 
>> 'user:pass:realm' (we can see this in the logs and code is provided below); 
>> however, apache is presenting the user with the login form each and every 
>> time authentication is successfully completed.
>>
>> Some things to note: The password (in this case) isn't a password at all. 
>> It is an encrypted cookie that is found in the HTTP_COOKIE variable. The 
>> process of validating that cookie is to send it over TCP to a propratary 
>> java-validation process. 
>>
>> Can anyone see (in the configs and code below) where I have missed 
>> telling Apache that the Authentication was successful?
>>
>> CONFIG httpd.conf:
>> <LocationMatch "^/private/">
>>      Options Indexes FollowSymLinks ExecCGI
>>      AuthType Digest
>>      #REALM PrivateArea 
>>      AuthName PrivateArea 
>>      AuthDigestProvider wsgi
>>      WSGIAuthUserScript /sites/www-python/lib/auth/plugin.py
>>      Require valid-user
>>      RewriteRule .* - [E=PROXY_USER:%{LA-U:REMOTE_USER},NS]
>>      RequestHeader set X-WEBAUTH-USER "%{PROXY_USER}e"
>> </LocationMatch>
>>
>> CODE plugin.py:
>> def get_realm_hash(environ, user, realm):
>>      C = http.cookies.SimpleCookie()
>>      C.load(environ.get('HTTP_COOKIE',''))
>>      cval = ''
>>      if not 'rocacheauth' in C:
>>           writelog("cookie not present")
>>           return None
>>      if 'rocacheauth' in C:
>>           cval = C['rocacheauth'].value
>>           port = 2500
>>           writelog(f"cookie value: {cval}")
>>           userdata = findSession(cval) # look on disk for saved session 
>>           if userdata: return(digest(userdata,realm))
>>      writelog(f"session not found")
>>      userdata = verifyCookie(cval,port=port)
>>      if userdata:
>>           writeSession(cval,userdata) #save to disk
>>           return(digest(userdata,realm))
>>      writelog(f"session not validated")
>>      return None 
>>
>> def digest(userdata,realm):
>>      hasher = hashlib.md5()
>>      uname = userdata[5]
>>      ustr = f'{uname}:barkbark:{realm}'
>>      writelog(f"validated user:{uname}")
>>      hasher.update(ustr.encode('UTF-8'))
>>      dgest = hasher.hexdigest()
>>      writelog(f"digest :{dgest}")
>>      return(dgest)
>>
>> LOG1 OUTPUT: 
>> # (user does not have a saved session on disk)
>> # login form is presented
>> 2021-06-14 17:28:19,326 - authn_plugin - INFO - validated user:nv596r
>> 2021-06-14 17:28:19,327 - authn_plugin - INFO - digest 
>> :7159b4ae7e3c2bd736dcf7c9c03d8e64
>> # login form is presented AGAIN
>>
>> LOG2 OUTPUT: 
>> # (user does have a saved session on disk):
>> # login form is presented
>> 2021-06-14 17:47:54,318 - authn_plugin - INFO - Session Located nv596r
>> 2021-06-14 17:47:54,318 - authn_plugin - INFO - validated user:nv596r
>> 2021-06-14 17:47:54,319 - authn_plugin - INFO - digest 
>> :9633784b6851713b93506f3201fd53b9
>> # login form is presented AGAIN
>>
>> -- 
>> 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/ba89bbc5-99cb-4ca2-80d4-eb13d37f8fffn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/ba89bbc5-99cb-4ca2-80d4-eb13d37f8fffn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "modwsgi" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/modwsgi/36iEHNSG-XM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/4AB4D13B-E14B-4028-AB97-40645BABF624%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/4AB4D13B-E14B-4028-AB97-40645BABF624%40gmail.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/CAF91A5A-2531-42AF-A993-200D279EBAA4%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/CAF91A5A-2531-42AF-A993-200D279EBAA4%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "modwsgi" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/modwsgi/36iEHNSG-XM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/EC84EECC-9A7C-46E7-8C21-FB8E5509CCDF%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/EC84EECC-9A7C-46E7-8C21-FB8E5509CCDF%40gmail.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/5e11c0f2-ff2c-4cb7-a7b0-68ba3192868an%40googlegroups.com.

Reply via email to