6

I've followed the guide:

Getting Started with Authentication with Mobile Services .NET for Windows Store

I'm able to run the service locally as long as I don't need to authenticate the user. I can also authenticate the user if I publish the service to Azure. But I want to be able to test and authenticate the user locally. How can this be done?

I'm using Live ID and I have the correct ClientID and ClientSecret set in the Web.config. When I attempt to call LoginAsync from the client the call fails with The request could not be completed. (Method Not Allowed)

** Update 2014-03-20 **

Based on the comments of Carlos and Henrik, I've updated my local service to look exactly like my server instance. I followed Scot Hanselmans excellent guide and now I have my service running locally on port 80 and port 443 with a completely valid SSL certificate. It's even running on the exact same https://xxxx.azure-mabile.net hostname.

With these changes, there is now no configuration difference whatsoever between running the app against my local machine or running it against Azure. I can go to https://xxxx.azure-mabile.net in the browser, get redirected to Live login, sign in, and get redirected back to the service successfully. In the browser it all works. However it still doesn't work in the app.

I attached the debugger, set CLR errors to "break when thrown" and I managed to trap the exception in the service. Here's what I see in the immediate window:

Immediate Window

The Response property is not helpful. It does not provide any additional information about the problem.

The only thing that stands out to me is that the app is trying to do a POST to /login/microsoftaccount while the browser would normally be doing a GET at this address (then getting redirected).

** Update #2 2014-03-20 **

After following Henriks guide for remote debugging I was able to load symbols and get a tiny bit more information:

"An existing connection was forcibly closed by the remote host"

The error code is 10054 (WSAECONNRESET) Connection reset by peer.

It appears the Live Authentication server may be forcibly terminating the connection, but only when I'm authenticating with the app. Again, authentication within the browser is fine. This, combined with the fact that /login/microsoftaccount is a POST from the app seems to suggest there is a problem with the authentication token I'm getting back from LiveClient.LoginAsync. I'll do some more digging...

Jared Bienz - MSFT
  • 3,550
  • 17
  • 21
  • If you go to the browser and try log in with `https://` instead of `http://`, does it still work? If I remember correctly the authentication in the Windows 8 app needs to be done via HTTPS. – carlosfigueira Mar 18 '14 at 21:05
  • Thanks Carlos. That doesn't appear to have addressed it. I've updated my question above and I've fully enabled HTTPS locally on port 443 with a valid trusted cert. That still is not working. – Jared Bienz - MSFT Mar 21 '14 at 02:08
  • I tried this too with no luck. I also configured external access to issexpress [link](http://stackoverflow.com/questions/3313616/iis-express-enable-external-request), entered client key and client secret to web.config and added client and server url's to google's developer dashboard. Fiddler reveals "invalid_client". – martinoss Mar 07 '15 at 07:13

2 Answers2

0

At the moment, it is set up so that you don't need authentication when running locally and access the service from localhost. In this case, anonymous access is let through (this is of course disabled while running in the cloud).

We don't really have a way for your to authenticate locally as redirect URIs won't work (they can't point to localhost as there is not way that Facebook, say, can resolve "localhost").

One option is that we somehow can mock the authentication locally and give you a token without connecting with the various identity providers. I am not sure exactly what that would look like but it is something we can consider.

Henrik

Henrik Frystyk Nielsen
  • 3,092
  • 1
  • 19
  • 17
  • Thanks Henrik. I appreciate that authentication is not required while running locally, but I need to be able to uniquely identify the user. My service stores a lot of information for each individual user and not knowing who they are defeats the purpose of the app. So it's much less about authentication and much more about identification. When you get a moment, please see my updates to question above. My local service is now running on 80 and 443 with a valid cert. It's also "impersonating" my azure-mobile.net url so Facebook doesn't have to redirect to localhost. Sadly it's still not working. – Jared Bienz - MSFT Mar 21 '14 at 02:09
  • did you ever find a fix or workaround? like you i don't really need to "authenticate" any one, as much as I need to test the scenario of an authenticated user to ensure they are correctly connected to their data in the app. is remote debugging on the live app the only way to test this, and I have to build it blind? – SelAromDotNet Sep 24 '15 at 06:45
0

Did you perhaps set Mobile client app: Yes in your Live Connect project? I think that setting is meant to be used with the Live Connect SDK (client) flow, not the browser-based (server) flow. The client flow isn't supported yet with a .NET backend.

You also want to make sure you are using LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount) on the client to trigger the server flow.

Yavor Georgiev
  • 654
  • 3
  • 9
  • I'm pretty sure I tried it with that setting both ways, but I can test again. Are you saying that setting that to "No" should cause it to hit the LoginController with GET instead of POST? Can you provide more information about the differences between these two login flows? How can a Windows 8 app use server-based login flow instead of client login flow? – Jared Bienz - MSFT Mar 25 '14 at 22:26
  • Just changed it to false and attempted to log in again. Same error of Method Not Allowed. Looks like it's still attempting to do a POST. – Jared Bienz - MSFT Mar 25 '14 at 22:32
  • I suspect you may be using the wrong Login method on the client, see my edit. – Yavor Georgiev Mar 25 '14 at 22:44
  • Okay, this DID work. However I have two significant problems with this approach: First and foremost, my service code (and therefore the login) is all handled in a shared PCL. The single parameter version of LoginAsync that you requested me to use is in the platform-specific assembly Microsoft.WindowsAzure.Mobile.Ext. That method cannot be called from a PCL. Only the version that accepts a JObject can be called in the PCL. – Jared Bienz - MSFT Mar 26 '14 at 14:07
  • Using the version you proposed instead would require a significant refactoring of my service library since my PCL takes care of other operations during login process (gathering user data, registering for push notifications, etc.) Though I could look into that refactoring, it still doesn’t solve the second significant problem I have with this approach: It disables single sign on. I don’t see any way for me to click the “accept” button like I used to and have the app auto log me in every consecutive time I run it. – Jared Bienz - MSFT Mar 26 '14 at 14:08
  • In fact, now I have to log in with full email address and password every time the app is started. That’s actually pretty painful. Especially during development. How long until the client authentication flow is supported? – Jared Bienz - MSFT Mar 26 '14 at 14:08
  • Hi Jared, regarding the first issue, see [this example](http://hashtagfail.com/post/56006227192/portable-apps-mobile-services-pcl) showing you how to cleanly factor this out. Regarding the second issue, you're right that the SSO experience when you use the Live Connect SDK is much better... we aim to support the client flow in the near future. You can make the server flow sort of do SSO by following step 6 in the "Register your app" section of [this tutorial](http://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-windows-store-dotnet-get-started-users/) – Yavor Georgiev Apr 09 '14 at 19:00