login, redirects, and multiple apps

[Dave S]

I have a server with one web2py instance  (fronted by nginx/uwsgi), two apps, and a routes.py that says app1 is default.

I recently (that is, last night) added a new function to app2, protected (as usual) with @auth.requires_membship('innercircle').  In addition, I had to create a new user 'goodguy' and add it to 'innercircle'.  I tested from a browser instance that also had routine use of app1.   I spent a lot of time that was supposed to be for testing the form in trying to get logged in correctly.  I eventually tried .../user/profile, and found I was not getting logged in as 'goodguy', I was getting logged in as 'ordinaryjoe', an id that existed in both app1 and app2 (independent DBs, both sqlite3).  Also, even though I was specifying 'host:app2/default/newfunc,' I was being redirected to 'host:user/login?next=newfunc', which looks like (when login doesn't fail) it ends up trying to find newfunc in app1.  Being explicit about 'host:/app2/default/user/login?next=app2/default/newfunc' didn't seem to help.

I finally opened a tab in a different browser, and was able to get to the right place, but it seemed like a lot of Sturm und Drang by that time.  For the record, server web2py 2.15.4, python 2.7.13, aws linux; clients Firefox 58.0.2, Chrome 63.0.3239.132, on W10. Also, the successful effort was on Chrome, and today I used the dev tools to record the network activity for the form submit (I'm preparing to use curl to submit the form), and I could see from the request headers that there was session id cookie for both app1 and app2 (yes, I've used app1 on that browser, also).
 
Should I be doing something in routes.py to make all this work better, or are the user functions problematic in the 1x web2py 2x apps scenario, or was I just a victim of browser caches?

Dave S
/dps

[Massimo Di Pierro]

This is all very strange since web2py uses different cookie names, session id, and session folders for different apps. Therefore I do not see how things can get mixed up.

The only thing I can think of is if something in routes is accidentally redirecting form app1 to app2 or vice versa. This would not still not cause any session mixed up but it may cause you to see the profile of app1 while you think you are seeing the profile of app2 (assuming you were logged in both).

Can you email me your routes.py? Also, it there any way I can try this myself or reproduce it?

massimo

[Dave S]

On Wednesday, March 28, 2018 at 9:35:22 AM UTC-7, Massimo Di Pierro wrote:

This is all very strange since web2py uses different cookie names, session id, and session folders for different apps. Therefore I do not see how things can get mixed up.

The only thing I can think of is if something in routes is accidentally redirecting form app1 to app2 or vice versa. This would not still not cause any session mixed up but it may cause you to see the profile of app1 while you think you are seeing the profile of app2 (assuming you were logged in both).

Can you email me your routes.py? Also, it there any way I can try this myself or reproduce it?

massimo

I started with the sample routes.py, and tweaked this part:

#  This simple router set overrides only the default application name,
#  but provides full rewrite functionality.

routers = dict(

    # base router
    BASE=dict(
        default_application='myapp1',
        root_static = ['favicon.ico', 'robots.txt'],
    ),
)

The logins I was trying to do were for privileged accounts, and I don't yet have a handy demo site for the issue.

The browser I was using when getting confused was Firefox (on W10), 59.0.1 (or a recent predecessor).
Moving the 2nd login to Chrome resolved the issue.

(FWIW:  For a site that's not mine, but for a service provider we use to manage some provisioning needs, I had to go from one browser with two logins to two browser with one login each; again, FF was the browser where the two stopped working, and Chrome the browser I moved one of the logins to.  Each login was to a different portal, similar to having 2 identical apps with separate databases.  So FF's cookie management might have changed.)

/dps