locked
How can localhost in the Identity return email get back to the User 's email acct? RRS feed

  • Question

  • User-1245365310 posted

    Hi,

    In asp.net web forms and c# and while setting up the Identity framework that sends an email to the user that the user must respond to before access is granted.  The email gets to the user's email ok, but does not get back to the web site that is trying to be authenticated.  In the email, the link is going to localhost, and I am confused as why localhost, because the link is now in the user's web client and localhost for it is different from localhost on the machine that sent the email to the user origionally.  This is being run via run project in VS2019 on the dev machine.  Is there some voodoo going on here?  Or what?

    Thanks,

    Stanley

    Friday, October 16, 2020 7:19 AM

All replies

  • User753101303 posted

    Hi,

    And this email content is generated how ? My guess is that localhost is hardcoded rarher than being generated from the current site address.

    Friday, October 16, 2020 10:02 AM
  • User-1245365310 posted

    Hi PatciceSc

    >> And this email content is generated how ?

    From ASP.Net Identity Framework where a new user registers that triggers an email to the user.  The user clicks on the link which sends something back to the Identity Framework so the user's record can be marked as validated before authorization can be granted.  The link in the user's email is where localhost is shown.  And at this point, the email is at the user's mail client and nowhere near the originating server where the Identity stuff is at.  Somehow, when user clicks the link, it has to find its way back to the Identity stuff so completion of the user's authentication can be completed.

    Here is the link in the user's email, and I don't see how in the world it can find its way back to the originator:

    http://localhost:60254/Account/Confirm?code=ZvYJiAmuAr8SjHkQdbvB...........Cn%2bQJD58gg7Y05f85BJszgAgkU&userId=e0ab8874-5bf9-4888-88a7-ca4aa4cfd55c

    >> My guess is that localhost is hardcoded rarher than being generated from the current site address.

    If so, it was the Identity Framework.  Is there a config file somewhere that Identity got this from.  I know I didn't set it anywhere.

    Thanks, Stanley

    Friday, October 16, 2020 5:39 PM
  • User475983607 posted

    The email link is generated using the current hosted domain.  localhost:60254 will be replaced by a domain name once the application is deployed to a remote web server. 

    Friday, October 16, 2020 6:39 PM
  • User-1245365310 posted

    >> The email link is generated using the current hosted domain. 

    So, is it fair to say this Identity stuff cannot be tested in a dev environment.  I did substitute a real domain name as shown below and it failed.  https://www.dezzzzm.com:60254/Account/Confirm?code=ZvYJiAmuAr8SjHkQdb....................szgAgkU&userId=e0ab8874-5bf9-4888-88a7-ca4aa4cfd55c

    Would it fail because of the encrypted values coming from http://localhost:60254 MAY be different than from https://www.dezzzzm.com:60254

    Thanks, Stanley

    Friday, October 16, 2020 7:53 PM
  • User-943250815 posted

    deedroom@hotmail.com

    Would it fail because of the encrypted values coming from http://localhost:60254 MAY be different than from https://www.dezzzzm.com:60254

    No it fails because www.dezzzzm.com at DNS (if domain exist), does not resolve to localhost, when registered at DNS Server, it will resolve to public a IP address.

    To have www.dezzzzm.com resolved locally, you can register it at hosts file of your computer, so any request to it will be resolved to localhost
    https://support.acquia.com/hc/en-us/articles/360004175973-Using-an-etc-hosts-file-for-custom-domains-during-development

    Friday, October 16, 2020 8:28 PM
  • User475983607 posted

    deedroom@hotmail.com

    So, is it fair to say this Identity stuff cannot be tested in a dev environment.  I did substitute a real domain name as shown below and it failed.  https://www.dezzzzm.com:60254/Account/Confirm?code=ZvYJiAmuAr8SjHkQdb....................szgAgkU&userId=e0ab8874-5bf9-4888-88a7-ca4aa4cfd55c

    Your response does not make sense.   The domain must remain the same regardless of the environment.  This is true for any web application that persists user data in a cookie.

    deedroom@hotmail.com

    Would it fail because of the encrypted values coming from http://localhost:60254 MAY be different than from https://www.dezzzzm.com:60254

    It would fail because localhost and www.dezzzzm.com are two different domains.  How is it possible that your dev environment switches domains?

    Friday, October 16, 2020 8:38 PM
  • User-1245365310 posted

    >> It would fail because localhost and www.dezzzzm.com are two different domains.

    I agree as I see no way for a link on YOUR machine that references localhost to ever get back to www.dezzzzm.com.  Note that I manually edited the link containing localhost to www.dezzzzm.com in an effort to help it get back to where the original email came from, and stated that did not work.

    >> How is it possible that your dev environment switches domains?

    Good question.  I'll try breaking down the setup a little better.  Systems on dev machine.  Builtin IIS web server, Firefox browser, VS2019pro, c# app with Identity Framework installed that needs tested (which is what I'm doing here),

    The config file for the c# app contains credentials for a mail server to use.  That works as the email containing the authentication link successfully makes its way to YOUR inbox, wherever in the world you are.  If you look at the source code for the link in the email, it is:  
    http://localhost:60254/Account/Confirm?code=ZvYJiA....gkU&userId=e0ab8874-5bf9-4888-88a7-ca4aa4cfd55c

    I would suspect that when I ran the c# app within the dev env VS2019 using Firefox as its browser it created the url containing localhost and emailed it to you.  That works as you received it ok.  To finish up the authentication step, you need to click the link, and somehow, magically it finds its way back and authenticates you..  As I see it, with localhost being part of the url, that can never happen.  What and where needs changed to get the localhost replaced by a url that can find its way back?  How do I test this within the VS2019 env as VS is firing up the builtin version of IIS?

    Another related question.  Where is the link actually going?  To a web service that the dev version of IIS is listening to, or some other way?  And what about getting it past the firewall hours later?  Is there any white papers that explains the entire round trip processes involved?

    Hope that helps explain it better.

    Also when you say DNS and such, please include the perspective of what machine you are referring to such as:

    DNS on your machine that your machine uses to lookup the link's url,,

    DNS for dev machine that IIS is on,

    DNS for something else?

    You said edit the host file on what machine?

    Saturday, October 17, 2020 2:42 AM
  • User-1245365310 posted

    No it fails because www.dezzzzm.com at DNS (if domain exist), does not resolve to localhost, when registered at DNS Server, it will resolve to public a IP address.

    Resolving to a public ip address only gets it to our edge router, so how does it find its way through the router to the machine that generated the link?

    Thanks, Stanley

    Saturday, October 17, 2020 2:48 AM
  • User753101303 posted

    Let's see first how it should work. When creating a mail with a link back to a site, the usual approach is to use the host name of the current http request. So if testing on localhost it will use localhost. If you click the link and your site still runs in VS I don't see why it would not work.

    Now if you deploy the same app to site.com, when using this site the link will use site.com rather than localhost. Changing the domain name liokely "won't work" (especially it they don't share the same db).

    Now I'm not sure what is your exact situation:
    - you are testing on your dev machine and you think the mail will still include localhost once deployed on your real production site?
    - or your app is already deployed to the production site but mails are still send using a link back to localhost ?

    For now it seems you are perhaps in case #1 ie anticipating a problem that you likely won't have?

    Edit: you are using ASP.NET 4.x or ASP.NET Core? In short the mail is generated using for example System.Web.HttpContext.Url.Host to create a link back to the same site used to generated the mail. And so it works regardless of how your dev, test or prod site is named.

    if you keep your site up and running in VS, you should be able to click the link on your own machine and get back at the appropriate location on your development site.

    Saturday, October 17, 2020 9:06 AM
  • User-943250815 posted

    Resolving to a public ip address only gets it to our edge router, so how does it find its way through the router to the machine that generated the link?

    If you want, "in development", use domain name, ask help for someone from network to make proper adjustments for you. These adjustments can be a DNS Record and if necessary a Port Forward on edge router

    As already said, when deployed localhost will be replaced by domain name.
    You can make your tests on your development machine and confirm if your mail confirmation process is working fine, once deployed it will work as expected.

    Saturday, October 17, 2020 11:28 AM