Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix state propragation of the backup codes provider #10465

Merged
merged 1 commit into from
Aug 2, 2018

Conversation

ChristophWurst
Copy link
Member

@ChristophWurst ChristophWurst commented Jul 31, 2018

Starting with Nextcloud 14, the server knows the enabled/disabled
state of 2fa providers. While it will query that information if it's
unknown (on first use), it won't notice any changes. Thus, providers
have to propagate that information themselves.

Ref nextcloud/twofactor_totp#263
Ref nextcloud/twofactor_u2f#210
Ref https://github.com/orgs/nextcloud/projects/4#card-10826964


Test steps

  1. Switch to master
  2. Make sure you don't have backup codes generated, if you have, create a new account.
  3. Log in and create backup codes
  4. Configure another 2FA provider
  5. Log out
  6. Log in

Expected behavior

See regular 2FA provider and backup codes option.

Actual behavior

See regular 2FA provider, but miss backup codes option.

To see the expected behavior on this branch, you'll have to re-generate the backup codes.

@ChristophWurst
Copy link
Member Author

Remark: I couldn't execute the BackupCodeStorageTest because php segfault'ed. In the hope that it's an issue with my local php version/build, I've pushed anyway.

I'm now crossing my fingers and hope that it works on CI 🤞

@ChristophWurst
Copy link
Member Author

ChristophWurst commented Jul 31, 2018

Forgot to import a class, so pushed a fixup.

  • TODO: squash commits once this has received a positive review and CI passes

use OCP\IUser;
use Symfony\Component\EventDispatcher\Event;

class CodesGenerated extends Event {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to use the GenericEvent instead, because that allows other apps to also listen to the event. Otherwise they would need to cast to this specific class of another app to get the user info.
new GenericEvent($user)

And access with $event->getSubject()

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, my intention is not to share this event with other apps. It's meant to be used internally only. Second, I like this custom event class better because it offers a type-safe way of transporting the user/subject. The GenericEvent is, well, generic 😉.

These are minor issues. If you insist on the change, I'll happily do so. I just wanted to give you my point of view.


use Symfony\Component\EventDispatcher\Event;

interface IListener {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since the interface can not be used by other apps drop it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it's not necessary to have an interface here. But having an interface is not only helpful when types are shared across apps. They make sure that the listeners implement a certain interface. This is purely used to keep the code clean and maintainable.

Again, I can remove it if you prefer to have it simpler. We're back at duck typing then, though.

@rullzer
Copy link
Member

rullzer commented Jul 31, 2018

Failing CI https://drone.nextcloud.com/nextcloud/server/9338/95

Copy link
Member

@rullzer rullzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine by me :)

@rullzer rullzer added this to the Nextcloud 14 milestone Aug 1, 2018
Starting with Nextcloud 14, the server knows the enabled/disabled
state of 2fa providers. While it will query that information if it's
unknown (on first use), it won't notice any changes. Thus, providers
have to propagate that information themselves.

Ref nextcloud/twofactor_totp#263
Ref nextcloud/twofactor_u2f#210

Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
@ChristophWurst ChristophWurst force-pushed the fix/backup-codes-state-propagation branch from 3a4b53f to f8fe748 Compare August 1, 2018 19:21
@ChristophWurst
Copy link
Member Author

Commits squashed and rebased onto latest master 🚀

@MorrisJobke MorrisJobke mentioned this pull request Aug 1, 2018
51 tasks
@ChristophWurst
Copy link
Member Author

@nickvergessen please see my comments. Is this okay to integrate as is or do you want me to change that? We should have this in beta2 ✌️

@rullzer rullzer mentioned this pull request Aug 2, 2018
3 tasks
Copy link
Member

@nickvergessen nickvergessen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐘

@rullzer rullzer merged commit e194dc7 into master Aug 2, 2018
@rullzer rullzer deleted the fix/backup-codes-state-propagation branch August 2, 2018 08:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants