using web.py openid authentication with modwsgi
strattonbrazil
I run web.py's webser directly, it works, so I'm guessing it's not a
problem with my code but how apache/mod_wsgi stores files. When I run
the web.py server directly, the openid library will create
a .openid_secret_key file. If this file doesn't exist or gets deleted
by the next request, everyone is "logged out" and the file gets
recreated. I can't confirm this is the problem, but I was wondering
if anyone had any reason why storing an encryption store as a file
would work with web.py but not with mod_wsgi. Running the code, the
key file isn't being created in my cgi-bin. Where would file reads/
writes go to?
Here's an example I pulled from http://log.liminastudio.com/programming/howto-use-openid-with-web-py.
It works when I run this locally, but doesn't using mod_wsgi. The
only difference I can imagine is this file write. Can anyone get this
example to run correctly with mod_wsgi?
import web, web.webopenid
urls = (
r'/openid', 'web.webopenid.host',
r'/', 'Index'
)
app = web.application(urls, globals())
class Index:
def GET(self):
body = '''
<html><head><title>Web.py OpenID Test</title></head>
<body>
%s
</body>
</html>
''' % (web.webopenid.form('/openid'))
return body
if __name__ == "__main__": app.run()
Graham Dumpleton
A few points to note.
Apache processes run as a special user and may not have ability to
read/write to the required directory.
The current working directory of an Apache process is NOT the
directory of the script file and you therefore cannot use relative
paths but must use absolute paths.
Apache/mod_wsgi can run in a multi process and/or multi thread
configuration and distinct processes/threads may be interfering with
each other.
Have a read of:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
for more detail on these sorts of issues.
Graham
strattonbrazil
Graham Dumpleton
Since web.py is somewhat dated, you may be better off using a more
modern framework such as Flask. For Flask there is available
Flask-OpenID. See:
http://packages.python.org/Flask-OpenID/
Otherwise you should hassle web.py maintainers.
Graham
Josh Stratton
may check flask out for future projects or refactorings. I decided
that mod_auth_openid should fit my needs for now.
> --
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>
Josh Stratton
correctly as I see the main function called on every browser request.
in my site-enabled file...
WSGIDaemonProcess app processes=2 maximum-requests=500 threads=1
WSGIProcessGroup app
WSGIScriptAlias /myapp /var/www/cgi-bin/test.py
I believe the reason that the original web.py openid lib is failing is
it's restarting every time. Even if mod_wsgi is working correctly,
will using the library fail if it's running on multiple processes
since user requests might not hit the same instance consecutively? I
see there are apache processes being created as I increase the proces
to the daemon process, but should that still cause my test.py app to
start every frame?
Here's the end of web.py app.
app = web.application(urls, globals(), autoreload=False)
application = app.wsgifunc()
if __name__ == "__main__":
error("starting main")
app.run()
Graham Dumpleton
> One issue I'm seeing is that my app might not be setup with mod_wsgi
> correctly as I see the main function called on every browser request.
That could only be if process is crashing. Look in main Apache error
log for 'Segmentation fault' messages.
Also modify LogLevel directive in Apache and set it to:
LogLevel info
This will cause mod_wsgi to output messages about daemon process
start/stop and WSGI script loading so you can see more about when
stuff happening.
> in my site-enabled file...
>
> WSGIDaemonProcess app processes=2 maximum-requests=500 threads=1
Don't use 'maximum-requests' unless you have a good reason to. Should
never be used in a production site if you can avoid it.
Also initially suggest you use:
WSGIDaemonProcess app threads=1
Ie., a single process with a single thread. This will ensure requests
go back to same process and that it isn't due to multiprocess nature
of the configuration.
> WSGIProcessGroup app
> WSGIScriptAlias /myapp /var/www/cgi-bin/test.py
>
> I believe the reason that the original web.py openid lib is failing is
> it's restarting every time. Even if mod_wsgi is working correctly,
> will using the library fail if it's running on multiple processes
> since user requests might not hit the same instance consecutively? I
> see there are apache processes being created as I increase the proces
> to the daemon process, but should that still cause my test.py app to
> start every frame?
>
> Here's the end of web.py app.
>
> app = web.application(urls, globals(), autoreload=False)
> application = app.wsgifunc()
>
> if __name__ == "__main__":
> error("starting main")
> app.run()
The 'if' is redundant as only applies to when script run on command
line. Comment it out and see if script still works. If it doesn't then
you may actually be running your script as CGI through missing
configuration, although that would be dependent on app.run() running
it as a CGI script as opposed to a standalone server.
Graham