ASP.NET Core Web API how to temporary save verified phone number










1














I have an asp.net core web api application with asp.net core identify.
In my registration page I have to verify user phone number. In order to do this, I am using twilio which is great. My registration page is built as a wizard. In the second step the user verifies his phone and only in the end of the wizard, a request is made to create the user. My problem is that the twilio code verification can not be used twice. So if I am using it in the second step I can't use it again for the real create request. I need a way to assign this phone number to the user before the registration request occuers. Session could have been great if it was not a web api . I thought about creating a security token with the user verified phone number . This token will be attached to the create request and will have an expiration date. When the user will verified his phone in the second phase the server will return a token with phone and expiration to the client . This will be send along with the user data in the create request. I am not sure this is the right way to do it, and if it is I will really appreciate some help about how to create this token (all the examples I found was creating token for existing user )










share|improve this question


























    1














    I have an asp.net core web api application with asp.net core identify.
    In my registration page I have to verify user phone number. In order to do this, I am using twilio which is great. My registration page is built as a wizard. In the second step the user verifies his phone and only in the end of the wizard, a request is made to create the user. My problem is that the twilio code verification can not be used twice. So if I am using it in the second step I can't use it again for the real create request. I need a way to assign this phone number to the user before the registration request occuers. Session could have been great if it was not a web api . I thought about creating a security token with the user verified phone number . This token will be attached to the create request and will have an expiration date. When the user will verified his phone in the second phase the server will return a token with phone and expiration to the client . This will be send along with the user data in the create request. I am not sure this is the right way to do it, and if it is I will really appreciate some help about how to create this token (all the examples I found was creating token for existing user )










    share|improve this question
























      1












      1








      1







      I have an asp.net core web api application with asp.net core identify.
      In my registration page I have to verify user phone number. In order to do this, I am using twilio which is great. My registration page is built as a wizard. In the second step the user verifies his phone and only in the end of the wizard, a request is made to create the user. My problem is that the twilio code verification can not be used twice. So if I am using it in the second step I can't use it again for the real create request. I need a way to assign this phone number to the user before the registration request occuers. Session could have been great if it was not a web api . I thought about creating a security token with the user verified phone number . This token will be attached to the create request and will have an expiration date. When the user will verified his phone in the second phase the server will return a token with phone and expiration to the client . This will be send along with the user data in the create request. I am not sure this is the right way to do it, and if it is I will really appreciate some help about how to create this token (all the examples I found was creating token for existing user )










      share|improve this question













      I have an asp.net core web api application with asp.net core identify.
      In my registration page I have to verify user phone number. In order to do this, I am using twilio which is great. My registration page is built as a wizard. In the second step the user verifies his phone and only in the end of the wizard, a request is made to create the user. My problem is that the twilio code verification can not be used twice. So if I am using it in the second step I can't use it again for the real create request. I need a way to assign this phone number to the user before the registration request occuers. Session could have been great if it was not a web api . I thought about creating a security token with the user verified phone number . This token will be attached to the create request and will have an expiration date. When the user will verified his phone in the second phase the server will return a token with phone and expiration to the client . This will be send along with the user data in the create request. I am not sure this is the right way to do it, and if it is I will really appreciate some help about how to create this token (all the examples I found was creating token for existing user )







      asp.net asp.net-core access-token sms-verification






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 12 at 13:46









      Ron Yaari

      164




      164






















          1 Answer
          1






          active

          oldest

          votes


















          0














          Multi-step submission processes are anachronisms in an API scenario. Clients should be able to submit all the information at once. If you need to verify the phone number, there should be a separate endpoint for that, one that deals solely with that particular piece of functionality.



          In other words, the client should make a post to a "create user" endpoint with all the information needed to successfully create a user, and the user should be created immediately. A separate request then would be made by the client to verify the phone number. If you don't want the user to be able to user their account before verifying the phone number, you can make that a requirement, but the user object should be persisted regardless. If you like, you could implement some sort of maintenance process to purge any user records that do not have verified numbers after some period of time.






          share|improve this answer




















          • Hi Chris, You are absolutely right about your approach, but unfortunately if I will add isPhoneVerified to the user I will need to change the login and since I have mobile clients, I really don't want to do this (It affects many aspects in my system). Also in the registration phase from the user point of view, I want him to verify his phone in the second step in the creation wizard. So I can't use the same code to validate him again.
            – Ron Yaari
            Nov 12 at 14:31










          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53263523%2fasp-net-core-web-api-how-to-temporary-save-verified-phone-number%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          Multi-step submission processes are anachronisms in an API scenario. Clients should be able to submit all the information at once. If you need to verify the phone number, there should be a separate endpoint for that, one that deals solely with that particular piece of functionality.



          In other words, the client should make a post to a "create user" endpoint with all the information needed to successfully create a user, and the user should be created immediately. A separate request then would be made by the client to verify the phone number. If you don't want the user to be able to user their account before verifying the phone number, you can make that a requirement, but the user object should be persisted regardless. If you like, you could implement some sort of maintenance process to purge any user records that do not have verified numbers after some period of time.






          share|improve this answer




















          • Hi Chris, You are absolutely right about your approach, but unfortunately if I will add isPhoneVerified to the user I will need to change the login and since I have mobile clients, I really don't want to do this (It affects many aspects in my system). Also in the registration phase from the user point of view, I want him to verify his phone in the second step in the creation wizard. So I can't use the same code to validate him again.
            – Ron Yaari
            Nov 12 at 14:31















          0














          Multi-step submission processes are anachronisms in an API scenario. Clients should be able to submit all the information at once. If you need to verify the phone number, there should be a separate endpoint for that, one that deals solely with that particular piece of functionality.



          In other words, the client should make a post to a "create user" endpoint with all the information needed to successfully create a user, and the user should be created immediately. A separate request then would be made by the client to verify the phone number. If you don't want the user to be able to user their account before verifying the phone number, you can make that a requirement, but the user object should be persisted regardless. If you like, you could implement some sort of maintenance process to purge any user records that do not have verified numbers after some period of time.






          share|improve this answer




















          • Hi Chris, You are absolutely right about your approach, but unfortunately if I will add isPhoneVerified to the user I will need to change the login and since I have mobile clients, I really don't want to do this (It affects many aspects in my system). Also in the registration phase from the user point of view, I want him to verify his phone in the second step in the creation wizard. So I can't use the same code to validate him again.
            – Ron Yaari
            Nov 12 at 14:31













          0












          0








          0






          Multi-step submission processes are anachronisms in an API scenario. Clients should be able to submit all the information at once. If you need to verify the phone number, there should be a separate endpoint for that, one that deals solely with that particular piece of functionality.



          In other words, the client should make a post to a "create user" endpoint with all the information needed to successfully create a user, and the user should be created immediately. A separate request then would be made by the client to verify the phone number. If you don't want the user to be able to user their account before verifying the phone number, you can make that a requirement, but the user object should be persisted regardless. If you like, you could implement some sort of maintenance process to purge any user records that do not have verified numbers after some period of time.






          share|improve this answer












          Multi-step submission processes are anachronisms in an API scenario. Clients should be able to submit all the information at once. If you need to verify the phone number, there should be a separate endpoint for that, one that deals solely with that particular piece of functionality.



          In other words, the client should make a post to a "create user" endpoint with all the information needed to successfully create a user, and the user should be created immediately. A separate request then would be made by the client to verify the phone number. If you don't want the user to be able to user their account before verifying the phone number, you can make that a requirement, but the user object should be persisted regardless. If you like, you could implement some sort of maintenance process to purge any user records that do not have verified numbers after some period of time.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 12 at 14:17









          Chris Pratt

          151k20233298




          151k20233298











          • Hi Chris, You are absolutely right about your approach, but unfortunately if I will add isPhoneVerified to the user I will need to change the login and since I have mobile clients, I really don't want to do this (It affects many aspects in my system). Also in the registration phase from the user point of view, I want him to verify his phone in the second step in the creation wizard. So I can't use the same code to validate him again.
            – Ron Yaari
            Nov 12 at 14:31
















          • Hi Chris, You are absolutely right about your approach, but unfortunately if I will add isPhoneVerified to the user I will need to change the login and since I have mobile clients, I really don't want to do this (It affects many aspects in my system). Also in the registration phase from the user point of view, I want him to verify his phone in the second step in the creation wizard. So I can't use the same code to validate him again.
            – Ron Yaari
            Nov 12 at 14:31















          Hi Chris, You are absolutely right about your approach, but unfortunately if I will add isPhoneVerified to the user I will need to change the login and since I have mobile clients, I really don't want to do this (It affects many aspects in my system). Also in the registration phase from the user point of view, I want him to verify his phone in the second step in the creation wizard. So I can't use the same code to validate him again.
          – Ron Yaari
          Nov 12 at 14:31




          Hi Chris, You are absolutely right about your approach, but unfortunately if I will add isPhoneVerified to the user I will need to change the login and since I have mobile clients, I really don't want to do this (It affects many aspects in my system). Also in the registration phase from the user point of view, I want him to verify his phone in the second step in the creation wizard. So I can't use the same code to validate him again.
          – Ron Yaari
          Nov 12 at 14:31

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53263523%2fasp-net-core-web-api-how-to-temporary-save-verified-phone-number%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          這個網誌中的熱門文章

          How to read a connectionString WITH PROVIDER in .NET Core?

          Museum of Modern and Contemporary Art of Trento and Rovereto

          In R, how to develop a multiplot heatmap.2 figure showing key labels successfully