mirror of
https://github.com/nextcloud/twofactor_gateway.git
synced 2026-04-25 09:05:55 +03:00
[GH-ISSUE #100] Recovery keys #31
Labels
No labels
0. to triage
1. to develop
3. to review
blocked
bug
discussion
duplicate
enhancement
enhancement
gateway:signal
gateway:signal
gateway:signal
gateway:sms
gateway:telegram
hacktoberfest
help wanted
invalid
needs info
php
pull-request
question
technical debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/twofactor_gateway-nextcloud#31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @morph027 on GitHub (Aug 27, 2018).
Original GitHub issue: https://github.com/nextcloud/twofactor_gateway/issues/100
This just crosses my mind:
When enabling 2F like this, we should probably spit out some recovery keys like with TOTP (if I remember).
@ChristophWurst commented on GitHub (Aug 27, 2018):
Haven't found about that scenario but yes, this needs some error handling. Do you happen to know if the gateway will communicate this error via its REST API?
@ChristophWurst commented on GitHub (Aug 27, 2018):
Generally, people should generate backup codes for these situations. However, we currently can't enforce that (yet).
@morph027 commented on GitHub (Aug 27, 2018):
Not sure if it's possible with the Signal app...anyway, we can add a notice on how to act in this case (manually deleting the file on the gateway).
I can catch the error and answer accordingly.
@morph027 commented on GitHub (Aug 27, 2018):
New version should return
{'success': False, 'error': 'remote identity is not trusted'}in case it happens.