Azure Mobile App - Strange API result only on .NET - vb.net

Edit:
As of 3/21/2017, even after upgrading from Azure client SDK version 2 to 3.0.1, this is still a problem. So... bump.
I have an Azure Mobile App with custom authentication. I am developing a client for iOS and a client for Windows (VB.NET WinForms).
On iOS, everything works just fine. Registration and Login work, and also a standard API call.
On WinForms, all of the pieces works fine, just not exactly when and how I want (i.e., not all of the time).
Registration works.
Login works.
Standard API call works.
What doesn't work is the standard API call after a Login event.
I have put a console.log() line in my API code, and in all cases, it gets to the line just before the res.json() finishing call.
Here's how I am assigning my user to the client in iOS:
NSString *token = dict[#"token"];
NSString *userId = dict[#"userId"];
MSUser *user = [[MSUser alloc] initWithUserId:userId];
[user setMobileServiceAuthenticationToken:token];
client.currentUser = user;
Here's how I am assigning my user to the client in VB.NET:
Dim token = result.Item("token")
Dim userId = result.Item("userId")
Dim user As New MobileServiceUser(userId)
user.MobileServiceAuthenticationToken = token
MobileService.CurrentUser = user
So, the standard workflow is as follows:
User logs in
Program calls standard API method
On iOS, this works flawlessly. I see the log entry on the API output and it immediately returns the correct information to the iOS app.
On Windows.NET, the following 2 scenarios exist:
If I skip the login process and just call the standard API method (which has been set to access "anonymous"), it works.
If I force the login process and then call the standard API method, the code just hangs forever. The log entry does show up on the API output, but waiting several minutes on the .NET debugger yields no output and no error message. It's just (apparently) hung indefinitely.
So, from what I can tell, the following statements apply:
The API code seems to run the same way every time, no matter which platform is calling the code.
The iOS code seems to run correctly.
Logging in always seems to go fine on either platform.
The .NET code runs fine if the *.json permissions are "anonymous" and no Login attempt has been made.
The .NET code breaks (i.e., hangs indefinitely) if the standard API call is sent after logging in.
This would seem, then, to be related to something happening to the MobileServiceClient during my LoginWithResult method. But, from what I can see, it's the EXACT same code (effectively) on both iOS and Windows.
Does anybody see a flaw in my thinking or code?

Related

xero-api Initialise Problems

I have attempted to set up xero-node passing in the consumer key and consumer secret along with the app name as the user Agent. However when I do a test call e.g. xeroClient.core.users.getUsers() the code just seems to freeze not giving any errors however I cannot move any further.
Are you able to post a gist of the code you are using?
What App type are you using (Private, Public or Partner)?
Have you seen the code samples on the main GitHub page? There is also a sample app here: https://github.com/XeroAPI/xero-node-sample-app

GoogleTokenResponse.getIdToken() returns null

Our server OAuth validation via Google has started throwing NullPointerException within GoogleTokenResponse.parseIdToken():
java.lang.NullPointerException:
at com.google.api.client.json.webtoken.JsonWebSignature$Parser.parse(JsonWebSignature.java:462)
at com.google.api.client.googleapis.auth.oauth2.GoogleIdToken.parse(GoogleIdToken.java:57)
at com.google.api.client.googleapis.auth.oauth2.GoogleTokenResponse.parseIdToken(GoogleTokenResponse.java:106)
This is new behavior that started today. There was no change to our server code (it has worked for months). The problem occurs only with credentials from one Android device -- I have another that works fine. Refreshing the client's server access token does not solve the problem.
The GoogleTokenResponse is being created by GoogleAuthorizationCodeTokenRequest(), that call succeeds and when I log the GoogleTokenResponse it looks valid:
{"access_token":"ya29.mwJvM...","expires_in":3600,"token_type":"Bearer"}
UPDATE: tested some more and found tokenResponse.getIdToken() is returning null, so I assume that's what's causing the NPE when I call parseIdToken().
What would cause getIdToken() to return null when GoogleAuthorizationCodeTokenRequest() apparently succeeded and there is an access token?
Final resolution: this issue appears to be triggered intermittently by the Google Play Services update in early 2016 to anonymize PlayerID. We were able to fix our problems by changing our server validation of the access token to a newer method instead of relying on the older getIdToken()/parseIdToken() methods. See the last UPDATE below for details
After two days the Android device with this failure mysteriously started to work again. So the cause may be a transient error in the client's Google Play Services state which self-corrected. The fix occurred after a device reboot.
However I'm not certain that was the cause. There are also Play Services changes rolling out to enable authentication without exposing the G+ user ID -- another explanation is the server was not being given scope to retrieve the ID. (If that was the cause, then again the fix must have been deployed by Google as we have not changed anything)
We'll continue to monitor it, if anyone else runs into this add a comment please.
4/19/16 This problem has occurred on a different device. I am wondering if this is related to the Google Play auth changes described here http://android-developers.blogspot.com/2016/01/play-games-permissions-are-changing-in.html?m=1
That explanation is a bit sparse but it does say "The user_id returned by token info may no longer be present with the new model. And even if it is present, the value won’t be the same as the new player ID"
In this case the problem occurred after
Device had previously authorized with Google Play Services in the old G+-style
App data was cleared so re-auth was necessary
During re-auth GPS prompted for the new GPS-only player ID (not real name), which makes me wonder if it switched that device to the new non-G+ ID
Then server calls to tokenResponse.getIdToken() returned null
I'm not yet sure what's happening but researching two areas of concern:
1) Although the Google docs referenced above say "existing players ... will continue to get their Google+ ID" I'm wondering if this is managed per-client. That would be a big problem because we use that ID to store cloud state for a user across devices, so if a user who originally set up their account before the new player ID then installed the app on a second device, they could sign in with gplay but the two accounts would not match
2) If this is the cause, then either our server code fails to work with the new non-G+ player ID, or there is a google back-end bug when a device transitions between the two. This is still confusing though because our prior problem did self-correct after a couple of days, which implies the server code is fine -- but I'm sure hoping the alternate explanation of a bug with google back-end auth is wrong!
--- UPDATE
I think the issue is related to the new GPS anonymized PlayerID changes. It has been hard to debug because it appears that Google's legacy server auth flow, which requires a non-null GoogleTokenResponse.getIdToken(), fails for a newly created GPS PlayerID, but after 12-24 h the problem seems to self-correct and the legacy Google auth calls begin to succeed including returning a non-null getIdToken().
However I tried implementing the new PlayerID flow in the Step 7 of the google info page above which converts the access token (generated from a server auth code) to a Player ID via www.googleapis.com/games/v1/applications//verify/
This code successfully retrieves a Player ID from the accessToken even when getToken() returns null:
// URL: www.googleapis.com/games/v1/applications/<app_id>/verify/
URL url = new URL("https://www.googleapis.com/games/v1/applications/" + GPlayServicesAppId + "/verify/");
HttpURLConnection httpConnection = (HttpURLConnection) url.openConnection();
httpConnection.setRequestProperty("Authorization", "OAuth " + accessToken);
httpConnection.setRequestMethod("GET");
int responseCode = httpConnection.getResponseCode();
if (responseCode != HttpURLConnection.HTTP_OK) {
...
}
BufferedReader reader = new BufferedReader(new InputStreamReader(httpConnection.getInputStream()));
String responseJson = (read contents of reader)
// Example response: { "kind": "games#applicationVerifyResponse", "player_id": "11520..."}
I ran some tests, far as I can tell the new method works in all cases where the older G+ getToken() method works as well as fixing the cases where it doesn't, so I believe we can just switch to the new method in the code snippet above and hopefully that will be reliable.

Philips Hue API: Remove application/username from bridge in order to start over

I'm using the HueSDK_iOS and everything seems to work fine.
I have one simple question for which I cannot seem to find a simple answer.
I want to test my app's functionality whenever a new user installs it.
I cannot find a proper way to de-authenticate my app from the bridge, so it will ask again to search for bridges etc and I can start over, to test everything.
I /did/ use :
cache = [PHBridgeResourcesReader readBridgeResourcesCache];
PHBridgeConfiguration *config = [cache bridgeConfiguration];
PHBridgeSendAPI *sendAPI = [[PHBridgeSendAPI alloc] init];
[sendAPI removeWhitelistEntryWithUsername:[config username] completionHandler:^(NSArray *errors) {
...
}];
and in the first time, it returns no errors, but I still am authenticated and can use the API , control lights etc, no notification arrives for disconnection or noLocalConnection.
If I run it again, I get an error: error = {\n address = \"/config/whitelist/_a_user_name\";\n description = \"resource, /config/whitelist/_a_user_name, not available\";\n type = 3;\n
(where a "_a_user_name" is the automatically generated username)
but I still keep being authenticated to the bridge.
So it seems it does delete the username from the whitelist, but still everything works as if I was authenticated.
So the question is simple: How do I remove my app from the bridge so I can start over and test all the steps? (Pushlinking etc)
It appears it is a bug in the bridge software as I was informed by Philips API support. They asked me to wait for an update.
According to this it can only be done through https://account.meethue.com/apps starting with API version 1.31.0.

IBM Worklight 6.1.0.1, trouble with 2 adapters based authentication

I am facing to a trouble with 2 adapters based authentication. My app is agenda (hybrid app). All adapter's functions must be protected by security.
my app uses adapters based authentication, like written in samples on DeveloperWorks.
My first adapter (loginAdapter) is dedicated for login (beginning of the mobile app). I developed a handler (handlerLogin, mobile side) with methods isCustomResponse, handlechallenge, etc.. This adapter works.
This adapter allows to get a userId from login and password.
As soon as connected, the user can download his agenda. The mobile calls an other adapter based auth (calendarAdapter). I have an other handler (handlerCalendar) with methods (isCustomResponse, handlechallenge).
When the mobile calls the method getCalendarData (protected method, CalendarAdapter), the server detects that the user is not registered for this adapter, that is why the server send an error (structure authrequired + errorMessage) via the function onAuthRequired.
At this step, all works fine.
Actually, the trouble comes from, that, the first handler (handlerLogin) catches this error, whereas it schould be the second handler (handlerCalendar).
Given that it is catched by the handlerLogin, isCustomResponse and handlechallenge are called, and I do not have the expected result ! I do not know why.
Why it is not catched by the handlerCalendar ?
I verified my code, variable's names, files, etc.. All things are ok.
For informations, I first declared the handlerLogin before the CalendarLogin.
Do you have any ideas, suggestions ??
Thank you in advance
It looks like you used the same realm.
The isCustomResponse function job is to find out if this challenge-handler should take care of this specific request. If you use the same realm for both adapters then the 2 challenge-handlers will react to it.

Soft "Restart" Windows 8 App

I'm going to preface this by saying that I understand the new Windows 8 application lifecycle and how it is now 100% up to the user to decide if they want to terminate the app or not. So, I guess what I'm looking to find is a way to pseudo-restart my app, although I'm open to other suggestions as I'm pretty new to designing Modern UI apps.
I'm building an app that interfaces with a Web 2.0 service that requires authentication via OAuth. Fortunately the Windows 8 WebAuthenticationBroker makes this simple: it displays an asynchronous modal window that houses the web frame to allow the user to sign in and I get to provide a callback method when its done.
Now, obviously I only want to display this sign-in screen if I don't already have a session key stored for the user in roamingSettings.values. I used the Grid App template in Visual Studio, and I execute these functions in default.js as soon as the app is activated (checking roamingStorage, calling WebAuthBroker, etc). Now, the Grid App template provides a data.js to allow me to define some of the REST endpoints that I want to fetch. The main problem is that I can't fetch these REST endpoints until the user is authenticated! Yet they still have to (at least, I think) be declared in data.js ahead of time. So what I'm doing now to avoid errors in the event that the user isn't signed in, is the following:
if (roamingSettings.values[sessionKey]){
list = getFeedItems(); // my function that issues all the REST calls
} else {
list = new WinJS.Binding.List();
}
This works fine if the app is manually restarted after authentication is complete, but I would really rather have a way of completely reloading the app asynchronously after authentication is complete. I've spent a ton of time on this already and I'm getting extremely annoyed because I've seen other apps do this (Instametrogram, for example).
Any ideas?
To answer the core question here, how do you soft restart: window.location.reload() is all you need. This just does the refresh in place.
However, what you are actually looking to do is reset the datasource on the ListView instance -- all you need to do is get hold of that control at runtime, and re-assign the data source to it. E.g.:
var lv = document.getElementById("myListView");
lv.winControl.itemSource = list;
An example of this should also be in the app you have from when it currently assigns the list to the listview.