Can no longer log in to /manage on beta.onezoom.org

[hyanwong]

I can't access /manage in beta.onezoom.org, even with a correct username/password.

EDIT

Weirdly, the problem seems to be the auth object which is used to contain the user's authentication details after login, and is either being zapped or never being updated. This doesn't happen in other web2py apps, so OZtree is doing something weird.

(the stuff below was fixed but the logging-in problem isn't, and is still replicable on a local install)

---

I'm getting this in the beta.onezoom.org_uwsgi_stderr.log:

WARNING:root:Unable to write to file applications/OZtree/languages/en-us.py
ERROR:web2py:Traceback (most recent call last):
  File "gluon/main.py", line 425, in wsgibase
    create_missing_app_folders(request)
  File "fileutils.py", line 520, in create_missing_app_folders
    try_mkdir(amf)
  File "gluon/fileutils.py", line 495, in try_mkdir
    os.mkdir(path)
PermissionError: [Errno 13] Permission denied: 'applications/admin/databases'

So I guess the installation script needs to make some of those directories writeable by www too?

[hyanwong]

Also lots of e.g.

WARNING:root:Unable to write to file OZtree/languages/zh-cn.py

In the logs. We should probably chown all the OZtree/languages/* files to www when we run grunt?

[hyanwong]

I created the directories languages, databases, uploads, sessions, and errors in admin and changed their ownership to match the OZtree ones, and it looks like create_missing_app_folders() is trying to create private too, so I made that. Still no joy logging in though :(

[hyanwong]

I also see this in the supervisord logs

set additional group 1005 (web)

I wonder if we were previous using the web user as an overall group for web2py, www, etc?

[hyanwong]

A few more pointers: If I remove the @OZfunc.require_https_if_nonlocal() from e.g. the index() function in manage.py it doesn't do anything. Also the logins are being correctly recorded in the auth_event table (e.g. it says User 5 Logged-in when I give the correct username/password, but it still redirects to the login screen as if nothing has happened)

[hyanwong]

Making some progress here. On my local machine, if I log in, then print out auth.user and session.auth.user from a page, they are different:

    print("auth.user is", auth.user)
    print("session.auth.user is", session.auth.user)

Gives

auth.user is None
session.auth.user is <Row {'id': 5, 'first_name': 'Yan', 'last_name': 'Wong', ...}>

I think that auth and session.auth should be the same. So somehow the auth object isn't being updated correctly after login

[davidebbo]

@hyanwong I found the problem using git bisect. The commit that broke it is 5b8cb59, which adds this to db.py:

    session.connect(request, response, db)

If you remove this line, it should work, though not sure what side effect that may have.

[davidebbo]

Ideally, we'd get to the bottom of why using db sessions breaks auth. But since this is a new thing and everything was working well before without it, it seems reasonable to remove it.

@lentinj your comment in 5b8cb59 says "Not that we should be using sessions much, if at all." Can you see any downside to removing this?

When not using it, the session data gets save in the sessions folder. In my experience (with other systems), db session is mostly useful when running on multiple servers, in a way that requests from one user can arbitrarily go to any server. Though even in such cases, db sessions are not needed when using 'sticky sessions', making sure that requests from one user always go to the same server.

[davidebbo]

Did a bunch of debugging and figured it out: we're calling session.connect() too late in db.py. It needs to be called before the auth = Auth(db) call. That then makes everything work with the db session. Sent PR.

[lentinj]

We should probably chown all the OZtree/languages/* files to www when we run grunt?

No, we should be disabling the language re-generation, and putting it behind another config option. It only serves to slow beta down, and having python-writable python files which are executed on each request is an obvious chink in our armour. We also set ourselves up for merge conflicts.

[lentinj]

"Not that we should be using sessions much, if at all." Can you see any downside to removing this?

The main reason for switching to DB sessions was to simplify the backup strategy, as well as the web2py book hinting that DB sessions are the happy path in production. These aren't overly strong reasons though, I'd be happy switching back if you'd not already figured it out.

[davidebbo]

The main reason for switching to DB sessions was to simplify the backup strategy, as well as the web2py book hinting that DB sessions are the happy path in production. These aren't overly strong reasons though, I'd be happy switching back if you'd not already figured it out.

Since the issue is now resolved (see above), we may as well stay with DB sessions, unless we run into additional problems.

[hyanwong]

Agreed. I'll close this now.