Merge lp:~mardy/ubuntuone-credentials/signon-plugin-part2 into lp:ubuntuone-credentials
| Status: | Rejected |
|---|---|
| Rejected by: | Natalia Bidart on 2017-05-19 |
| Proposed branch: | lp:~mardy/ubuntuone-credentials/signon-plugin-part2 |
| Merge into: | lp:ubuntuone-credentials |
| Prerequisite: | lp:~mardy/ubuntuone-credentials/signon-plugin-part1 |
| Diff against target: |
793 lines (+430/-121) 13 files modified
data/ubuntuone.provider (+2/-2) debian/control (+1/-1) libubuntuoneauth/CMakeLists.txt (+4/-0) libubuntuoneauth/authenticator.cpp (+179/-0) libubuntuoneauth/authenticator.h (+71/-0) libubuntuoneauth/keyring.cpp (+52/-67) libubuntuoneauth/keyring.h (+3/-3) libubuntuoneauth/libubuntuoneauth.symbols (+2/-1) libubuntuoneauth/ssoservice.cpp (+35/-13) signon-plugin/tests/test_plugin.cpp (+58/-7) signon-plugin/ubuntuone-plugin.cpp (+19/-26) signon-plugin/ubuntuone-plugin.h (+0/-1) signon-plugin/ubuntuonedata.h (+4/-0) |
| To merge this branch: | bzr merge lp:~mardy/ubuntuone-credentials/signon-plugin-part2 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| unity-api-1-bot | continuous-integration | Needs Fixing on 2016-06-28 | |
| dobey (community) | 2016-04-28 | Needs Fixing on 2016-05-26 | |
| PS Jenkins bot | continuous-integration | Needs Fixing on 2016-04-29 | |
|
Review via email:
|
|||
Commit Message
Authenticate via the new signon plugin
Description of the Change
Authenticate via the new signon plugin
This adds a couple of new internal classes, under the "Internal" namespace. API and ABI compatibility is preserved.
- 248. By Alberto Mardegan on 2016-04-29
-
Move plugin dependency to lib, add version number
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:248
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| dobey (dobey) wrote : | # |
Some comments in-line, and where are the tests for the new code?
- 249. By Alberto Mardegan on 2016-05-27
-
Use Q_DECL_DEPRECATED
- 250. By Alberto Mardegan on 2016-05-27
-
handleSessionData is deprecated too
- 251. By Alberto Mardegan on 2016-05-27
-
include order
- 252. By Alberto Mardegan on 2016-05-27
-
Remove accountmanager singleton
- 253. By Alberto Mardegan on 2016-05-27
-
No UI for login()
| Alberto Mardegan (mardy) wrote : | # |
I added a few commits where I did all the easy/agreeable changes. Other remarks of you require more information.
I developed this branch trying hard not only not to break the API signature, but also to retain its functionality. However, in one of your comments you suggested to empty the Keyring:
I see that the SSOService::login() method is used in pay-service to double-check the user's credentials before a payment, and by the account plugin to create the account. As I understand it, this method performs a couple of different operations:
1) Logs into the U1 account, to check that the given params are valid
2) If they are valid, ensures that the account exists (if not, creates it)
In the case of pay-service, #2 wouldn't normally be needed, but it's an essential functionality for the account plugin, so either we preserve it, or we move it to the account plugin code. Any preference?
Then, about invalidating credentials: this thing was not required in my first implementation, because the signon-plugin was always checking the token validity before returning it, so it would automatically attempt to re-validate it if it was expired. But indeed, now we have to do this in the library. The only small issue with it, is that we need an additional member in the Keyring class to store this information, and we cannot add it without breaking the ABI.
So, three options:
1) we just add it and break ABI, if you are confident that we have no client using the Keyring class directly.
2) use QObject:
3) The Keyring private data currently are Accounts::Manager and Accounts::Account *. We could move enable PIMPL for this class if we replace these two private members with a union:
union {
struct {
} oldPrivateData;
};
Of course, we wouldn't use the members in oldPrivateData, they are needed just to keep the class size constant. That's also ugly, but then we don't have to worry when adding private members anymore.
Which one has your vote?
As for the unit tests, I'll add them later, once you are happy with the code (we'll have plenty of time while this thing is being tested in a silo).
| Alberto Mardegan (mardy) wrote : | # |
Ouch, I realized one important thing :-)
Now, when login() is called, we invoke the signon-plugin, which will (unless an OTP is given, but the OTP is not enabled for all U1 accounts) just return the cached token and not try to actually login with the given credentials. So, in the case of pay-service, the verification would actually be skipped, except for accounts having 2fa enabled.
Therefore I need to add some parameter to the signon plugin to tell it whether the cached token should be discarded.
And thinking of this, it occurs to me that this could also be the solution to the last issue I raised in my previous comment: the Keyring:
| dobey (dobey) wrote : | # |
On Fri, 2016-05-27 at 12:51 +0000, Alberto Mardegan wrote:
> I added a few commits where I did all the easy/agreeable changes.
> Other remarks of you require more information.
>
> I developed this branch trying hard not only not to break the API
> signature, but also to retain its functionality. However, in one of
> your comments you suggested to empty the Keyring:
> out and deprecate it, which would break any clients using it. If
> changes like this are allowed, then I'd need to know what are the
> methods which we need to keep functional, and those which could be
> removed. I can do some research myself, but maybe you can help me by
> giving some pointers on which projects I should be considering. Do I
> understand right, that the pay-ui repo is deprecated and that
> everything lives inside pay-service?
Functional here is a relative term. Keyring::storeToken shouldn't be
getting used directly by anything which links to libubuntuoneauth.
Really, the only classes which external apps/libs should be using are
SSOService and Token. Also, I hope we can do further cleanup, after
this lands, and break the API/ABI and get rid a lot of this old cruft
that's been left around. However, I wanted to avoid the work to add the
signon plug-in, and start using it, turning into a giant branch that
basically rewrites everything. So it's fine to make some things outside
the SSOService and Token classes be no-ops and deprecate them.
Yes, lp:pay-ui is dead. The pay-ui code is in pay-service now.
> I see that the SSOService::login() method is used in pay-service to
> double-check the user's credentials before a payment, and by the
> account plugin to create the account. As I understand it, this method
> performs a couple of different operations:
> 1) Logs into the U1 account, to check that the given params are valid
> 2) If they are valid, ensures that the account exists (if not,
> creates it)
> In the case of pay-service, #2 wouldn't normally be needed, but it's
> an essential functionality for the account plugin, so either we
> preserve it, or we move it to the account plugin code. Any
> preference?
The use of login() in pay-ui isn't a "double check" of the credentials.
It is a login. We require a fresh token when making purchases, so if
the user has not logged in during the past 15 minutes, we require them
to log in again to refresh the token. However, the design for the
purchase process requires that the login be part of that purchase flow,
and not a separate window that we pop up. We only pop up the external
U1 login window when there is no U1 account.
I'm not quite sure what you mean in #2 here. My understanding is that
all the actual work to do the login and store the token in the signon
db is done in the signon plug-in already. We need to continue calling
login from pay-service/pay-ui in order for the designed flow to work.
| dobey (dobey) wrote : | # |
On Fri, 2016-05-27 at 13:07 +0000, Alberto Mardegan wrote:
> Ouch, I realized one important thing :-)
> Now, when login() is called, we invoke the signon-plugin, which will
> (unless an OTP is given, but the OTP is not enabled for all U1
> accounts) just return the cached token and not try to actually login
> with the given credentials. So, in the case of pay-service, the
> verification would actually be skipped, except for accounts having
> 2fa enabled.
This must be fixed. The pay-service usage here isn't verification, it
is to refresh the token.
> Therefore I need to add some parameter to the signon plugin to tell
> it whether the cached token should be discarded.
It should always be replaced by a new token if login is successful. I
don't think we need additional parameters for that, but to just fix the
code so that it works this way.
> And thinking of this, it occurs to me that this could also be the
> solution to the last issue I raised in my previous comment: the
> Keyring:
> authentication with this flag specified, so that the signon-plugin
> would delete its cached token and the next time an app requires to
> authenticate, it will go through the full flow. I'll create a
> separate MP for this, OK?
I think Keyring:
flagged as deprecated, and SSOService:
do whatever is necessary to mark the credentials as invalid.
- 254. By Alberto Mardegan on 2016-05-30
-
Merge clear-cached-token branch
[ Alberto Mardegan ]
* Be more explicit about which headers are installed. Move the symbol
export map to LINK_FLAGS on the target.
* Complete the UbuntuOne authentication plugin
* Make Token::isValid() return false on tokens created out of empty
strings. (LP: #1572943) - 255. By Alberto Mardegan on 2016-05-30
-
Implement credentials invalidation
| Alberto Mardegan (mardy) wrote : | # |
On Fri, 2016-05-27 at 12:51 +0000, Alberto Mardegan wrote:
> I'm not quite sure what you mean in #2 here. My understanding is that
> all the actual work to do the login and store the token in the signon
> db is done in the signon plug-in already. We need to continue calling
> login from pay-service/pay-ui in order for the designed flow to work.
Weird, I thought I had replied, but something must have gone wrong. Trying again.
The signon-plugin does not create the account, it only cares about the credentials and other authentication data.
The account itself must be created by the account plugin; in its current incarnation, the account plugin is relying on libubuntuoneauth to create the account. This was triggered by calling SSOService:
So the question is: do we keep things like this, or should I investigate the possibility of moving the account creation directly in the account plugin?
| unity-api-1-bot (unity-api-1-bot) wrote : | # |
FAILED: Continuous integration, rev:255
https:/
Executed test runs:
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/
| Natalia Bidart (nataliabidart) wrote : | # |
Started a massive cleanup of old MPs, closing this given its age, please update and re-open if still valid.
Unmerged revisions
- 255. By Alberto Mardegan on 2016-05-30
-
Implement credentials invalidation
- 254. By Alberto Mardegan on 2016-05-30
-
Merge clear-cached-token branch
[ Alberto Mardegan ]
* Be more explicit about which headers are installed. Move the symbol
export map to LINK_FLAGS on the target.
* Complete the UbuntuOne authentication plugin
* Make Token::isValid() return false on tokens created out of empty
strings. (LP: #1572943) - 253. By Alberto Mardegan on 2016-05-27
-
No UI for login()
- 252. By Alberto Mardegan on 2016-05-27
-
Remove accountmanager singleton
- 251. By Alberto Mardegan on 2016-05-27
-
include order
- 250. By Alberto Mardegan on 2016-05-27
-
handleSessionData is deprecated too
- 249. By Alberto Mardegan on 2016-05-27
-
Use Q_DECL_DEPRECATED
- 248. By Alberto Mardegan on 2016-04-29
-
Move plugin dependency to lib, add version number
- 247. By Alberto Mardegan on 2016-04-28
-
Inject times into token
- 246. By Alberto Mardegan on 2016-04-28
-
WIP -- use plugin in libubuntuoneauth

FAILED: Continuous integration, rev:247 jenkins. qa.ubuntu. com/job/ ubuntuone- credentials- ci/155/ jenkins. qa.ubuntu. com/job/ ubuntuone- credentials- wily-amd64- ci/32/console jenkins. qa.ubuntu. com/job/ ubuntuone- credentials- wily-armhf- ci/32/console jenkins. qa.ubuntu. com/job/ ubuntuone- credentials- wily-i386- ci/32/console
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/ubuntuone- credentials- ci/155/ rebuild
http://