Zip file was too big, but here's a link to a sample project
Upon screen orientation, the ui stays on the enter password screen, as it does with our native Android library
Upon screen orientation, the ui reverts back to the original login screen with no username present (this value has been lost)
In our dev sample, we have this in the MainActivity:
[Activity(Label = "XForms", Icon = "@drawable/icon", Theme = "@style/MainTheme", MainLauncher = true,
ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)]
Here's the code in ADAL where we handle the embedded webview
Here's the similar issue in ADAL with screen shots
And a similar issue in msal
=====
Our native Android's code for their webview
and their manifest
@jennyf19 does this problem happen if you are not using Xamarin.Forms?
@jonathanpeppers Yes, I can repro this with a non-Xamarin.Forms app.
@jonathanpeppers We've had a few customers escalate this during the past week...is there a change we can make to ADAL/MSAL or is this a fix on your end? And, if a fix on your end, do you have an estimate of when the fix will be available? Thank you.
@jennyf19 do you have a sample that is just a Xamarin.Android app with a WebView? Just navigate to facebook.com or something?
@jonathanpeppers you can use this one in our adal repo
Does it work if you don't use MSAL or ADAL at all? Just a WebView going to some webpage with a username/password fields? (could be anything facebook.com or something)
@jonathanpeppers I tried w/FB (still using MSAL via B2C). For FB, the username and password fields are on the same page, but after entering the username, if I rotate the screen, I am sent back to the select an IdP page...I'm not even kept on the FB log-in screen, but sent back to the IdP selection screen.
So I created a Single View Application in VS 2019 16.1, added a WebView, and all I had to add to get this working was:
[Activity(ConfigurationChanges = ConfigChanges.Orientation | ConfigChanges.ScreenSize)]
Here is the sample: WebViewRotate.zip
Is your SDK doing something to prevent that form working? Does it override OnConfigurationChanged and do custom logic on orientation changes?
I'm not seeing anything we can fix in Xamarin.Android here? These are standard Android APIs, we just expose them to C# as-is. So the behavior you would get would be the same in Java or Kotlin?
So I created a
Single View Applicationin VS 2019 16.1, added aWebView, and all I had to add to get this working was:[Activity(ConfigurationChanges = ConfigChanges.Orientation | ConfigChanges.ScreenSize)]Here is the sample: WebViewRotate.zip
Is your SDK doing something to prevent that form working? Does it override
OnConfigurationChangedand do custom logic on orientation changes?I'm not seeing anything we can fix in Xamarin.Android here? These are standard Android APIs, we just expose them to C# as-is. So the behavior you would get would be the same in Java or Kotlin?
@jonathanpeppers No, that does not fix the issue. Here is what is happening with pictures and already using ConfigChanges.ScreenLayout and ConfigChanges.Orientation
https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/issues/1622
No OnConfigurationChanged, no special logic or anything like that. I think the ticket link above provides clear picture. I think the ADAL component internally uses WebView without giving us any control over how to make that view behave.
Even if I freeze orientation to Portrait before call to AcquireTokenAsync and unfreeze it after the call receives response, it still behaves same - it will still rotate the Microsoft sign in page even though I freeze it to Portrait on my MainActivity (which is the owner passed in PlatformParameters to the call to AcquireTokenAsync. So, my activity stays in portrait but that sign-in page still rotates and looses data. I think the link above will give you much clearer picture.
I think the ADAL component internally uses WebView without giving us any control over how to make that view behave.
Right, I don't know what we can do in Xamarin.Android for this? It seems like the fix would be in that component?
I think the ADAL component internally uses WebView without giving us any control over how to make that view behave.
Right, I don't know what we can do in Xamarin.Android for this? It seems like the fix would be in that component?
That I dont know but we are passing to AcquireTokenAsync everything accordingly and we are already setting the [Activity(ConfigurationChanges = ConfigChanges.Orientation | ConfigChanges.ScreenSize)] on our MainActivity which is passed in through PlatformParameters to AcquireTokenAsync.
Having said that, and from what I see, it is not Activity issue but the Microsoft's sign in page for ADAL. Perhaps the WebView inside it should take into consideration orientation settings on passed in activity and preserve data on rotation rather than loosing it and re-prompting for same again?
Even if you freeze orientation to Portrait before call to AcquireTokenAsync and unfreeze it after the call returns a response, you will see that that sign in page will still rotate and loose user entered info and reprompt for it again.
Any movement on the hot fix for ADAL to resolve this issue?
@dinobu this is on our radar. sorry for the delay. will keep you posted on progress. thanks.
@dinobu - @jonathanpeppers helped me identify a fix. If you can email me, I can send you a private build to try out and see if it addresses the issue for you as well. [email protected]
Again, apologies for this taking so long
@dinobu managed to squeeze this into the adal (5.1.1) release, we will need to retest and reevaluate the release, but will be out this week. will update here when that happens. Same fix will go into MSAL, and will be included in next MSAL release.
@dinobu managed to squeeze this into the adal (5.1.1) release, we will need to retest and reevaluate the release, but will be out this week. will update here when that happens. Same fix will go into MSAL, and will be included in next MSAL release.
Thank you so much @jennyf19. I will grab ADAL 5.1.1 once it gets released. Much appreciated.
@jennyf19 I'm closing for now, as I don't think there is a Xamarin.Android issue here, thanks!
@jonathanpeppers yes...thank you. thanks for your help w/this as well.
@dinobu @jonathanpeppers fix is out in ADAL 5.1.1
@dinobu @jonathanpeppers fix is out in ADAL 5.1.1
Any documentation on how to move from ADAL 3.x to 5.x? Thanks @jennyf19
@dinobu
There are no public api changes between 3.x and 5.2.0. The most significant change is the structure, in removing the platform dll...see more here on that.
We would recommend, instead, moving to MSAL.NET. If you need help w/the migration, let us know.
MSAL and ADAL are at parity, so all the features you have in ADAL are in MSAL, except for Android broker support, which is coming. Let us know if we can help.
@dinobu
There are no public api changes between 3.x and 5.2.0. The most significant change is the structure, in removing the platform dll...see more here on that.We would recommend, instead, moving to MSAL.NET. If you need help w/the migration, let us know.
MSAL and ADAL are at parity, so all the features you have in ADAL are in MSAL, except for Android broker support, which is coming. Let us know if we can help.
@jennyf19 Thank you for looking into this.
I would not say there is no breaking change as there was some breaking change btw 3.x and 4.x.
For example, I had to change this
https://login.microsoftonline.com/my-tenant-id/oauth2/authorize
,to this
https://login.microsoftonline.com/my-tenant-id
Also found this
https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/issues/1346
and this
https://stackoverflow.com/questions/53502733/powerbi-aadsts90002-tenant-authorize-not-found
@dinobu yes, you are correct. I forgot about the authority change. I'm pretty sure we have this documented, but need to surface it to a better place.
Thank you for the additional links as well.
@dinobu yes, you are correct. I forgot about the authority change. I'm pretty sure we have this documented, but need to surface it to a better place.
Thank you for the additional links as well.
No, I would like to thank you @jennyf19 @jonathanpeppers
Much appreciated for taking this and looking into it
Most helpful comment
@dinobu yes, you are correct. I forgot about the authority change. I'm pretty sure we have this documented, but need to surface it to a better place.
Thank you for the additional links as well.