locked
user not returning from redirect RRS feed

  • Question

  • We have had several complaints of users not returning from the redirect.

    We are using LiveID authentication. The behavior is

    - user (returning) successfully logs into LiveID
    - browser never returns 

    The link that appears when the browser bombs out is:

    https://account.healthvault.com/auth.aspx?appid=813C11EA-1B9C-11DD-AB99-FEB456D89593&redirect=https%3a%2f%2fspinnphr.com%2fusers%2fwelcome&lid=True&wa=wsignin1.0

    It seems to be unrelated to browser, but this is hard to debug. 

    I have tried using the account of one of these users and cannot reproduce the behavior (in this case, he was using IE 7 on XP), even though I have tried with the same browser/os combo.

    Any ideas?
    Tuesday, March 24, 2009 3:57 PM

Answers

  • Lowell,

    Thanks for the help. The problem, obviously, was that I couldn't reproduce the error. So, finally, I found someone with the issue, rdp'd in, and ran a header sniffer (used Live HTTP Header, add-on to Firefox).

    Turns out, the round trip is being stopped by google!! Here is the url that we get stuck at before we end up back at the app:

    http://static.cache.l.google.com/safebrowsing/rd/goog-malware-shavar_s_10481-10560.10481-10560

    the project home page for this phishing-preventing service is at:

    http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec

    I haven't yet sorted out how to solve the problem for this user, or others that might be having the same issue.

    That service is used by Firefox > 1.8 and probably other software packages. This user didn't have Firefox initially, so that's not it.

    I will report back when I find a solution.

    Ideally, we should be able to tell the safebrowsing reposity to white list urls like this. But we'll see.
    Thursday, March 26, 2009 8:56 PM

All replies

  • I checked this out in a few browsers, and the URL that appears to be bombing out isn't actually the one you sent above, but a later URL in the process (that URL ends up going through several redirects back to spinnphr.com):

    https://www.spinnphr.com/users/welcome/?target=AppAuthSuccess&wctoken=[edit]

    You can see this without the wctoken easily here, which is the standard Action URL redirect for App Auth Success:

    https://www.spinnphr.com/users/welcome/?target=APPAUTHSUCCESS

    You may want to look at your application at your end to see why the redirect isn't working at that point.  It appears, as best I can tell, that the HealthVault server-side is functioning appropriately at this point.

    Additional suggestion:

    A free tool is availble that is often invaluable in diagnosing this kind of problem.  It is called Fiddler, and was initially developed independently, but was acquired by Microsoft not too far back.  It's still free, and incredibly useful.  It acts as an HTTP (and HTTPS if you choose) proxy and captures all data being sent to and from your client, so you can see all the redirects and find out exactly where the errors are coming from.

    http://www.fiddler2.com/fiddler2/

    Make sure you do the additional steps to have Fiddler capture HTTPS traffic, as almost all HV traffic is HTTPS.  If you don't do this, you won't capture the necessary data.

    http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp
    Tuesday, March 24, 2009 5:59 PM
  • Lowell,

    Thanks for the help. The problem, obviously, was that I couldn't reproduce the error. So, finally, I found someone with the issue, rdp'd in, and ran a header sniffer (used Live HTTP Header, add-on to Firefox).

    Turns out, the round trip is being stopped by google!! Here is the url that we get stuck at before we end up back at the app:

    http://static.cache.l.google.com/safebrowsing/rd/goog-malware-shavar_s_10481-10560.10481-10560

    the project home page for this phishing-preventing service is at:

    http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec

    I haven't yet sorted out how to solve the problem for this user, or others that might be having the same issue.

    That service is used by Firefox > 1.8 and probably other software packages. This user didn't have Firefox initially, so that's not it.

    I will report back when I find a solution.

    Ideally, we should be able to tell the safebrowsing reposity to white list urls like this. But we'll see.
    Thursday, March 26, 2009 8:56 PM
  • Crazy-- I'm definitely curious to see how things turn out.  Let us know if you run into more trouble.

    I'm actually still having trouble pulling up the APPAUTHSUCCESS target at my end... I'm getting 504 proxy timeouts, which could in theory be due to our corporate proxy servers.  Is the following URL working for you?
        https://www.spinnphr.com/users/welcome/?target=APPAUTHSUCCESS
    Thursday, March 26, 2009 9:32 PM
  • yea. that works fine (minus we expect the wctoken in the query string, which throws a few minor errors). but the url can be called no problem.

    there doesn't seem to be a way to tell google to whitelist the objectionable url, unfortunately.

    so, i'm going to remove (hopefully with the user's permission) the IE google toolbar, and see if that fixes it.

    thanks
    Thursday, March 26, 2009 11:55 PM