WIP: Improve authentication cookies
This is in order to add extra protection against cross-origin requests as a way to fix #20181019-3CB56B.
In its current form, it breaks officejs which uses cross origin cookies.
added 6 commits
Toggle commit list
- 535e1c35 - oauth_google_login: reuse setAuthCookie
- 3ab994fe - oauth_google_login: inline getGoogleClientIdAndSecretKey
- 1ad9cf49 - oauth_facebook_login: minor BT definition fixes
- 6f20134d - oauth_facebook_login: reuse setAuthCookie
- 3d585385 - oauth_facebook_login: inline getFacebookClientIdAndSecretKey
- d2d4b8c4 - core: set SameSite=Lax on authentication cookie
added 8 commits
Toggle commit list
- cd2a8367 - testERP5Security: test how ERP5 sets cookie attributes
- b2123e0e - oauth_google_login: BT definition fixes
- c79e5e64 - oauth_google_login: reuse setAuthCookie
- 0453a1a0 - oauth_google_login: inline getGoogleClientIdAndSecretKey
- 62feb4d9 - oauth_facebook_login: minor BT definition fixes
- 992b660b - oauth_facebook_login: reuse setAuthCookie
- 839d8549 - oauth_facebook_login: inline getFacebookClientIdAndSecretKey
- e030adfc - core: set SameSite=Lax on authentication cookie
How to reproduce this problem with officejs app ? erp5_officejs_support_request_ui_test testLogin is passing... After thinking a bit, I think I understand the problematic scenario, it's when using an officejs app on one origin and using jio connector to access an ERP5 from another origin (which we don't cover in tests currently as they all use same origin). I did not consider this scenario.
The story here is that it seemed like an easy improvement, so I though "let's fix this problem quickly", but I completely missed this scenario. Now I don't see how we can improve this quickly. I cannot allocate the time to continue !138 or work on any other "more integrated login from officejs", so maybe we can close this for now.
BTW, about the testing, I have been thinking that we could add a scenario of cross origin usage of ERP5/JIO in a "normal" functional test. We could use an office js app ( with just some static html js ) hosted somewhere, for example https://test-remote-erp5.app.officejs.com/ . The test could be a selenium test doing something like:
- create something in the runUnitTest instance to be synchronized
- logs out the browser from the runUnitTest instance
- open https://test-remote-erp5.app.officejs.com/
- choose synchronize from ERP5
- enter the url of the runUnitTest instance
- login (which currently fail with this branch)
- proceed with synchronization
- inspect https://test-remote-erp5.app.officejs.com/ and check "something" was synchronized.
- ... we can also check that another origin app such as https://test-another-remote-erp5.app.officejs.com/ cannot use. ( which currently fail on master )
does it make sense ? is it worth making a silly app just for testing ( we could use an existing app) ?
All OfficeJS application functionnalities can't be tested with our test framework currently, and what you're describing look more like an integration/monitoring test on the OfficeJS urls: check that all storages (erp5, dropbox, etc) work as expected, check that site is not down, etc.
Maybe, this can be done with the scalability testing framework (no idea if it is possible). And duplicating the Zelenium macros to Selenium to reach somehow stable tests will take time.
This would be an ERP5 test (not OfficeJS test), checking that ERP5 uses authentication cookies that are compatible with cross origin access like OfficeJS does.
I don't really like it, but I felt it would be better than no test.
marked as a Work In ProgressToggle commit list