'registration' module woes

[midtoad]

I want to enable user registration and login in my web app. User
login and permissions are available out of the box, so to speak, but
not user registration. I found the registration module in the CogBin
and downloaded and installed it. I'm able to use it to edit details
of existing users, but when I try to register a new user, I always get
a Database Locked error. (I'm not running any other apps that access
the database, besides TurboGears that is).

Has anyone else used this module, and if so, have you seen this error
and how did you get over it?

[Christopher Arndt]

midtoad schrieb:

A little more information, please!

- Which database?
- SO or SA?
- Error message with traceback
- Output of "tg-admin info"
- and anything else that might be relevant.

Only then we can help you.

Chris

[midtoad]

On Mar 31, 10:22 am, Christopher Arndt <chris.ar...@web.de> wrote:

> A little more information, please!
> - Which database?

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) --> on Mac OS X
10.5.2.
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.version
'2.3.2'
>>> sqlite3.sqlite_version
'3.3.14'


> - SO or SA?

I'm afraid I don't know what this question means.

> - Error message with traceback

http://paste.turbogears.org/paste/2371
and another time I tried it the exceptions were slightly different but
still finished with the Operational error and the database locked:
http://paste.turbogears.org/paste/2385

> - Output of "tg-admin info"

Say, thanks for letting me know about that command. Interesting, and
below is the output. Note that I'm using the expat module from Python
2.4 in my Python 2.5 installation since the version that ships with
Python 2.5 is not compiled for use with Intel architecture.

fuerza:SpotPlot midtoad$ tg-admin info
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-
packages/_xmlplus/parsers/expat.py:4: RuntimeWarning: Python C API
version mismatch for module pyexpat: This Python has API version 1013,
module pyexpat has version 1012.
from pyexpat import *
TurboGears Complete Version Information
TurboGears requires:
* TurboGears 1.0.4.4
* TurboKid 1.0.4
* TurboJson 1.1.2
* TurboCheetah 1.0
* simplejson 1.8.1
* setuptools 0.6c8
* RuleDispatch 0.5a0.dev-r2306
* PasteScript 1.6.2
* FormEncode 1.0.1
* DecoratorTools 1.7
* configobj 4.5.2
* CherryPy 2.3.0
* kid 0.9.6
* RuleDispatch 0.5a0.dev-r2306
* Cheetah 2.0.1
* PyProtocols 1.0a0dev-r2302
* PasteDeploy 1.3.1
* Paste 1.6
* DecoratorTools 1.7

Toolbox Gadgets
* info (TurboGears 1.0.4.4)
* catwalk (TurboGears 1.0.4.4)
* shell (TurboGears 1.0.4.4)
* designer (TurboGears 1.0.4.4)
* widgets (TurboGears 1.0.4.4)
* admi18n (TurboGears 1.0.4.4)

Identity Providers
* sqlobject (TurboGears 1.0.4.4)
* sqlalchemy (TurboGears 1.0.4.4)

tg-admin Commands
* info (TurboGears 1.0.4.4)
* shell (TurboGears 1.0.4.4)
* quickstart (TurboGears 1.0.4.4)
* update (TurboGears 1.0.4.4)
* sql (TurboGears 1.0.4.4)
* i18n (TurboGears 1.0.4.4)
* toolbox (TurboGears 1.0.4.4)

Visit Managers
* sqlobject (TurboGears 1.0.4.4)
* sqlalchemy (TurboGears 1.0.4.4)

Template Engines
* kid (TurboKid 1.0.4)
* json (TurboJson 1.1.2)
* cheetah (TurboCheetah 1.0)

Widget Packages

TurboGears Extensions
* visit (TurboGears 1.0.4.4)
* identity (TurboGears 1.0.4.4)

> - and anything else that might be relevant.

If I use Python 2.4 instead of Python 2.5, the result is the same.
The request to register a new user ends in a time-out. If I try to
reload the page, I get the Database locked error.

Any suggestions on how I should troubleshoot this? Maybe just put
print statements throughout the registration controllers.py module?

[midtoad]

follow-up:

As I mentioned in my earlier post, when I try to register a new user,
the Submit just times out. Usually I get tired of waiting after a
minute or so and just re-submit the request. It looks as though that
is causing the Database Locked error. Here are the exceptions from
the time-out error: http://paste.turbogears.org/paste/2386

It looks as though the time-out occurs when the registration module
tries to send out the confirmation mail. Maybe I need to go make a up
a test script that tries to send a simple e-mail using the same smtp
server, and see what happens.

[midtoad]

problem solved!

The first registration request was timing out because the SMTP server
either wasn't responding, or not responding in a way that the script
understood.
when I send the second request, the database was still locked from the
first request.

I made up a small test program using the example from
http://www.eskimo.com/~jet/python/examples/mail/smtp1.html
and it became obvious how to interact with the smtp server.

thanks for your interest,
S

[midtoad]

[Jorge Vargas]

On Tue, Apr 1, 2008 at 5:28 AM, midtoad <stewart....@gmail.com> wrote:
>
> problem solved!
>
> The first registration request was timing out because the SMTP server
> either wasn't responding, or not responding in a way that the script
> understood.
> when I send the second request, the database was still locked from the
> first request.
>

I was just reading this and was thinking the same thing, I guess it's
a bug on the registration package. it will be a good idea to report it
even patch it should be easy by adding a timeout to the smtp call.

[Patrick Lewis]

On Apr 1, 1:28 am, midtoad <stewart.midwin...@gmail.com> wrote:
> problem solved!
>
> The first registration request was timing out because the SMTP server
> either wasn't responding, or not responding in a way that the script
> understood.
> when I send the second request, the database was still locked from the
> first request.
>

> I made up a small test program using the example fromhttp://www.eskimo.com/~jet/python/examples/mail/smtp1.html

> and it became obvious how to interact with the smtp server.
>
> thanks for your interest,
> S

Did you have to change something in the registration script, or were
you able to make it work by only modifying the configuration values?
If the former, I'd be interested in seeing your changes.

For what it's worth, the built-in mail handler isn't terribly robust
(as you've found out) and is really intended for development use only.
If you move the app to a production environment, be sure to install
and configure TurboMail as the mail handler.