webapps team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

Some updates:

On 11/25/2013 03:13 PM, Alberto Mardegan wrote:
> There are a few ways to address this issue; I will list only the two on
> the top of my head (though they are not originally mine, to be honest):
> 1) Until the authentication has completed, act like an ordinary web browser.
> 2) Delegate the authentication to Online Accounts.

We have decided to test this second option, to verify its feasibility. And:

> The main question I have is: should the webapp container have only read
> access to the cookies, or should we let it update them? In other words:
> should we simply copy all the cookies over from OA to the webapp when it
> starts (let's call this option #1), or should we also have a way for the
> webapp to modify the OA cookies (option #2)?

for this, we are testing option #1; so far, it seems that there isn't a
problem with reusing the same cookies more than once, but of course this
is something which depends on the site, and can change in the future.

If you want to replicate these tests, you will need:

- the "app-access" branch of ubuntu-system-settings-online-accounts:

https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/app-access

- the "export-cookies" branch of signon-ui:
  https://code.launchpad.net/~mardy/signon-ui/export-cookies

- The test code itself: https://github.com/mardy/cookie-test

if you run the tests on the desktop, you'll need to tell signon-ui to
use WebKit2; so, open a new terminal and type:

  export SSOUI_DAEMON_TIMEOUT=5000
  export SSOUI_USE_WEBKIT2=1
  signon-ui

and let it run while you create the accounts and perform the test. The
test currently supports only google and facebook; you can edit the
"provider" property near the top of src/qml/cookie-test.qml to choose
between the two.
Note that if you have existing accounts which you created on the
desktop, they will not work with this test (because they were most
likely created with a signon-ui backed by WebKit1). If needed, we can
extend signon-ui to be able to work with these as well.

To run the test, execute the cookie-test application. The first time it
should show you an empty screen with just an "Add new account" button.
Press it, create a new account (or grant access to an existing account,
but beware that it must have been created with the signon-ui + WebKit2,
or it won't work), and the new account should appear in the screen.
Tap it, and the website should open.


One more thing that the webapps container will have to do (which
currently the cookie-test doesn't do) is to check the timestamp of the
cookies it gets from signon-ui (I added a second output parameter to the
D-Bus method to return the timestamp of the cookies.db file used by
signon-ui), and use them only if they are newer than those stored in the
WebKit2 used by the webapp.
This is needed in the following scenario:
- Online Accounts cookies are expired (but the access token is still
valid, so no login happens in OA)
- A webapp is started, it gets the expired cookies from OA
- The user is asked to login into the webapp
- The webapp is closed
- The webapp is reopened
At this point, OA would still send the expired cookies (since we don't
have two-way synchronization), and the webapp would ask the user to
login every time.


Last, this is still an important issue still unsolved:

> Another issue to address with the OA integration is the expiration of
> the session: suppose that the session expires while the user is actively
> using the webapp; the user will be asked to login again, but at that
> point the webapp is confined to its usual domains, so Openid (or Google
> Apps) authentications will be blocked (or redirected to the default
> browser), which sounds like a terrible user experience.
> Any ideas for solving this? DOM tricks again? :-)

Ciao,
  Alberto