You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just got SMS 2FA working on my Nextcloud instance. It wasn't too bad, but I had to sign-up for an SMS gateway service. I'm willing to spend the ten cents or so for each 2FA text because I have very few users and we rarely logout.
A lot of (most? all?) cell carriers allow for sending text messages to a phone by sending an email to a specific email address that incorporates the cell phone's number. For example, to send a text message to a phone on the at&t wireless network, you can send an email to [phone number]@txt.att.net. Verizon is similar: [phone number]@vtext.com. If the app could be configured to send authorization codes to one of these email addresses, it would be equivalent (I think) to SMS 2FA, without requiring any sort of gateway setup.
I see two enhancements that would facilitate this use case:
Allow for specification of the 2FA email address, separate from the user's primary email address (essentially different email address for 2FA #177).
Allow for customization of the actual email content so that it can be formatted (shortened? - I haven't actually seen what the current email looks like) for better text message appearance.
I don't think there would be any need to explicitly call-out this use case. Just adding the necessary enhancements would allow people who are trying to setup SMS 2FA to figure it out. That's how I ended up installing this Nextcloud app; I thought, "Oh, maybe this email 2FA will let me email a text message." Alas, no - but so close.
The text was updated successfully, but these errors were encountered:
Seems to be a good idea at first glance. You already referenced the issue that would allow for your use case except for the customizable mail body. Thus I see this as an enhancement that depends on the implementation of #177.
Yet, pondering upon it made me think that the USER would need to choose the correct gateway as I assume that a provider will only accept to send to customers on HIS network, right? It seems not robust If a user would need to properly set up (1) the gateway URL, and templates to (2) e-mail subject and (3) body.
Yet, pondering upon it made me think that the USER would need to choose the correct gateway as I assume that a provider will only accept to send to customers on HIS network, right? It seems not robust If a user would need to properly set up (1) the gateway URL, and templates to (2) e-mail subject and (3) body.
Also, if the end user changed their cell provider, then their gateway would also need changing and they would need to be logged into Nextcloud to change the gateway before they changed their provider.
I just got SMS 2FA working on my Nextcloud instance. It wasn't too bad, but I had to sign-up for an SMS gateway service. I'm willing to spend the ten cents or so for each 2FA text because I have very few users and we rarely logout.
A lot of (most? all?) cell carriers allow for sending text messages to a phone by sending an email to a specific email address that incorporates the cell phone's number. For example, to send a text message to a phone on the at&t wireless network, you can send an email to [phone number]@txt.att.net. Verizon is similar: [phone number]@vtext.com. If the app could be configured to send authorization codes to one of these email addresses, it would be equivalent (I think) to SMS 2FA, without requiring any sort of gateway setup.
I see two enhancements that would facilitate this use case:
I don't think there would be any need to explicitly call-out this use case. Just adding the necessary enhancements would allow people who are trying to setup SMS 2FA to figure it out. That's how I ended up installing this Nextcloud app; I thought, "Oh, maybe this email 2FA will let me email a text message." Alas, no - but so close.
The text was updated successfully, but these errors were encountered: