I investigated further and I found I was guilty of missing very important thing in production config:
> #set debug = false I thought that this was the problem because I checked whether app is working in other browser. So it works like a charm in FF, IE and even Konqueror but it does not work properly in Opera. It has to do something bad to requests. Hope that this info will help to prevent someeone from shortening his lifespan over browser quirk. btw. turbogears is really cool Best regards and thanks for help! wAnt On 1 Gru, 15:32, working_ant <[email protected]> wrote: > Below I add my production.ini - this was the one generater by make- > config. > > What I have gained is that I changed a bit configuration of my > register.wsgi script > mounting my app not in directory /register/ but in the root directory > thus:http://10.0.0.1/serves my index. > > Now I get: Wrong credentials for > anything.http://10.0.0.1/login->http://10.0.0.1/login?__logins=1&came_from=/ > > Any other thing I might misconfigured? > > Best, > > wAnt > > # > # register - TurboGears configuration > # > # The %(here)s variable will be replaced with the parent directory of > this file > # > [DEFAULT] > # WARGING == If debug is not set to false, you'll get the interactive > # debugger on production, which is a huge security hole. > > debug = false > email_to = [email protected] > smtp_server = localhost > error_email_from = pa...@localhost > > [server:main] > use = egg:Paste#http > host = 0.0.0.0 > port = 80 > > [app:main] > use = egg:register > full_stack = true > cache_dir = %(here)s/data > beaker.session.key = register > beaker.session.secret = [cut] > app_instance_uuid = [cut] > > # If you'd like to fine-tune the individual locations of the cache > data dirs > # for the Cache data, or the Session saves, un-comment the desired > settings > # here: > #beaker.cache.data_dir = %(here)s/data/cache > #beaker.session.data_dir = %(here)s/data/sessions > # Specify the database for SQLAlchemy to use via > # turbogears.database > # %(here) may include a ':' character on Windows environments; this > can > # invalidate the URI when specifying a SQLite db via path name > #sqlalchemy.url = sqlite:///%(here)s/somedb.db > sqlalchemy.url=mysql://[c...@localhost:3306/register?charset=utf8 > sqlalchemy.echo = False > > # WARNING: *THE LINE BELOW MUST BE UNCOMMENTED ON A PRODUCTION > ENVIRONMENT* > # Debug mode will enable the interactive debugging tool, allowing > ANYONE to > # execute malicious code after an exception is raised. > #set debug = false > > # Logging configuration > # Add additional loggers, handlers, formatters here > # Uses python's logging config file format > #http://docs.python.org/lib/logging-config-fileformat.html > > [loggers] > keys = root, register, sqlalchemy, auth > > [handlers] > keys = console > > [formatters] > keys = generic > > # If you create additional loggers, add them as a key to [loggers] > [logger_root] > level = INFO > handlers = console > > [logger_register] > level = INFO > handlers = > qualname = register > > [logger_sqlalchemy] > level = DEBUG > handlers = > qualname = sqlalchemy.engine > # "level = INFO" logs SQL queries. > # "level = DEBUG" logs SQL queries and results. > # "level = WARN" logs neither. (Recommended for production systems.) > > # A logger for authentication, identification and authorization -- > this is > # repoze.who and repoze.what: > [logger_auth] > level = DEBUG > handlers = > qualname = auth > > # If you create additional handlers, add them as a key to [handlers] > [handler_console] > class = StreamHandler > args = (sys.stderr,) > level = NOTSET > formatter = generic > > # If you create additional formatters, add them as a key to > [formatters] > [formatter_generic] > format = %(asctime)s,%(msecs)03d %(levelname)-5.5s [%(name)s] % > (message)s > datefmt = %H:%M:%S > > On 1 Gru, 11:40, "Diez B. Roggisch" <[email protected]> wrote: > > > On Tuesday 01 December 2009 11:01:21 working_ant wrote: > > > > Thank you both for reply. > > > > 404 is from TG, after examination, I believe there is a problem with > > > paths as Diez has hinted out. > > > > Just to be on the safe side I will describe situation step by step: > > > > Application is mounted in its directory > > >http://10.0.0.1/register/ > > > > When I try to access admin TG asks me about credentials. > > >http://10.0.0.1/register/login > > > I fill them and I get 404: > > >http://10.0.0.1/register/register/login?__logins=1&came_from=/register/ > > > > From what Diez hinted I believe that a problem arises due to the fact > > > that there is one more /register > > > reference in the url. > > > > I didn't mess with authentication logic generated by quickstart and > > > post action is the default one from > > > the: templates/login.html > > > Can you post your production.ini-file as well? I'm not 100% sure, but it > > looks > > as if the PATH_INFO as well as some configured prefix (also named register) > > are combined. > > > Diez -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
