Xamarin.Auth uses WebView which is going to get deprecated by Google soon

Hello. My question is about the Xamarin.Auth component.

Internally it uses "embedded" browser to issue OAuth requests and provide UI. Google announced that such a way of authentication is deprecated:

Starting October 20, 2016, we will prevent new OAuth clients from using web-views on platforms with a viable alternative, and will phase in user-facing notices for existing OAuth clients. On April 20, 2017, we will start blocking OAuth requests using web-views for all OAuth clients on platforms where viable alternatives exist.

Is anybody at Xamarin going to finally update the component?

Tagged:

Best Answer

  • moljacmoljac HR ✭✭✭
    Accepted Answer

    Sorry for late response, but I had to finish few things 1st.

    @EvgeniyZverev said:

    @moljac said:
    @EvgeniyZverev

    Is anybody at Xamarin going to finally update the component?

    No. Until new features stabilize and new features are (very brief):
    1. Native UI support for Android (Custom Tabs) and iOS (SFSafariViewController)

    The component is long since outdated. "New features" and chrome custom tabs in particular have nothing to do with this.

    Have you ever written/implemented/packaged Xamarin.Component?
    I did. Quite a few. Component requires samples for each supported platform, docs and artwork. And this is quite substantial effort. Initial Xamarin.Auth team is partially on Xamarin.Forms team and some left Xamarin.

    To begin with the master branch does not support Windows 8.1, Windows Phone 8.1, UWP. Years passed.

    Windows Phone, WinRT support was added in early 2016. It was in nuget version 1.3.x for Evolve16 (2016-04-2x).

    What "stabilization" are you talking about??

    To enable some OAuth features that were not in present Xamarin.Auth like:

    • custom schemes,
    • different host support (localhost)
    • Native UI (with low level API support)
    • WKwebView support (in addition to UIWebView)

    a lot of refactoring was necessary.

    Very few sane people would expect no problems after such refactoring on existing codebase. Fixing those issue was meant under "stabilisation".

    Google published chrome custom tabs api 2 YEARS!! ago. A few days ago Google blocked old API. It's time for the transition to FINISH, not begin.

    The component is outdated, but the library itself was not. Simple peek into activity on GitHub and nuget would reveal that. We would be very happy with your PR with CustomTabs 2 years ago.

    FYI google announced ban for Embedded WebViews in 2016-08 and this is less than 2 years.

    Xamarin.Auth v.1.4.0 with first implementation of Native UI was published on 2017-03-30, before google's deadline. Quie a few people managed to implement OAuth with NativeUI before the deadline.

    Don't be silly.

    Nice.

    1. Xamarin.Forms support for everything (old + new AKA #1)

    I do not actually understand what you are talking about here. Please be more specific. No sarcasm, I am really curious.

    Version 1.4.0 was pushed before google's deadline, so the people could implement OAuth with Native UI, before deadline. Estimation was that 3 weeks (20 days) should be enough to do it. API refactoring was far from ideal, but 1.4.x came out. Then stabilized and switched to 1.5.0-alpha- with Xamarin.Forms support, because the pressure was to high and writing Custom Renderers was complicated.

    The reason it took longer were
    1. some restrictions in Xamarin.Auth,

    What restrictions?

    Xamarin.Auth never supported custom schemes. Never supported localhost or similar. When Authenticator constructor is created first request is already sent to the OAuth provider. It was necessary to "fit into old API" - that was design goal for new API.

    1. desire not to break old API (or to break it minimally)

    Again. I do not understand what are you talking about. Appending NEW features utilizing Chrome Custom Tabs, SFSafariViewController and WebAuthenticationBroker have nothing to do with the old API.

    It has. GetUI() returns login screen and a lot happens behind it.

    1. add flexible API for new features

    That's called expanding a library. When it lacks minimal vital functions...it's ridiculous.

    Maybe.

    I do not know if anyone at Xamarin is actually watching the project right now.

    Yes.

    Ask before jumping into false conclusions

    • here or
    • go to github and open issue,
    • send an email to Xamarin support,
    • go to community slack
    • XamarinHQ has facebook, twitter

    Well, I do not pretend to ask everywhere I could. The facts are:
    1. Last Xamarin.Auth release (version 1.2.3.1) is January 12, 2015. More than 2 years ago. Is that component alive?

    Define alive.

    It can still be used with most of the OAuth providers. Even with google, but the question is when will google cut it off.

    1. Have a look at the component questions: https://components.xamarin.com/view/xamarin.auth Do you find many of them addressed? Still looks alive?

    I'm aware of those comments. The problem is it is impossible to reply to those comments in the comment area, only by mail and that helps a little, because people simply do not check other sources of information (github, nuget, forums, community slack channel).

    1. Well...I asked here and several other xamarin forums. 2 months passed since a question got any attention.

    The problem is/was lack of time and daily tasks with higher priorities.

    I do understand that not all questions can be answered. Still I see a problem here.

    Sad story...Xamarin.Auth is long dead.

    This is your opinion. I'm happy there is a lot of people with different opinion.

    Here is pinned item on 2017-05-01

    https://xamarinchat.slack.com/archives/C4TD1NHPT/p1493666223953008

    You will not be able to see it, because of limited history for community slack channel, but here is the blog:

    https://subhamoyburman.wordpress.com/2017/05/01/google-oauth-xamarin-auth-ios-implementation-with-custom-tabssafaricontroller/

    So, 10 days after google's deadline people were able to blog about Xamarin.Auth Native UI support.

    Wrong. Check community slack and you will see 5+ success stories with Xamarin.Auth v >= 1.4.x.
    There is even demand from those users to add support for non-standard query parameters google introduced with this restriction.

    To say the truth I do now know what "community slack" is.

    Community slack is public slack team organised by community and joined by vaste majority of Xamarin engineering team to help users out.

    As for Xamarin.Auth v >= 1.4.x, it's not available for the general public since it is not published as a Xamarin Component release.

    Not having component does not mean that some SDK is not available for general public. Most of the SDK 3rd party vendors decide not to package component. Component is guarantee for those using it, that it is curated and safe. It provides samples and docs. Some components wrap nugets.

    https://developer.xamarin.com/guides/cross-platform/advanced/submitting_components/components_and_nuget/

    So, most developers push nugets first before going (if at all) for components. And this is the case with Xamarin.Auth.

    There is a live branch in the project that seems to be regularly updated which is hopelessly far from the
    master branch now.

    So, you checked github? How come it is dead? No commits on master means project is dead?
    Can you define "hopelessly far from the master branch" and explain what does that mean?

    1. No commits on master means project is dead? Yes, exactly.

    OK. This might be rule in your organisation. Xamarin recently introduced similar rule that master must be releasable. Still I know projects where this is not the rule.

    1. "hopelessly far from the master branch" means it will hardly be ever merged into master.

    I will have to disappoint you. It was merged.

    There is a chance it gets released as a new component or an incompatible new version

    Only your opinion and not based on facts. (See facts about API and stabilisation above)

    requiring complete new integration.

    Right now 20+ people needed no new integration.

    It should have been a year ago.

    I wish it too.

    Keeping the component aside from the master branch for 2 years actually means building up a new component in a hidden manner. It's the best way to hide one from public usage.

    Seems like you were the only one that was not able to "find it".

    I just coded everything for Android (Chrome Custom Tabs) and iOS (SFSafariViewController) myself from scratch.
    For Windows I left it as it was, WebAuthenticationBroker seems to fit all the needs (I coded against it myself a year ago, > Xamarin.Auth did not help here as well).

    Cool. I missed PR or link to the repo with permissive license.

    Do not compare my private restricted implementation which required like 30 work hours and a public developer
    component which requires a much higher skill level and a thousand of work hours.

    It was several hundreds of hours (with porting Google team's samples and preparing some other utilities).

    I do not pretend to to creating something useful for anyone but me and my customers here.

    OK. Finally agreeing.

    Besides, I do not flame Xamarin.Auth developers.

    Yes you do - believe me.

    Xamarin.Auth enabled me to quickly get into the topic and create my own component with a hot start. Profit.

    I'm glad to hear that.

    I do flame Xamarin project administration for the lack of attention to this much needed component.

    Cool.

    I will escalate your issue to Xamarin.Auth project administration right now of speaking, because project manager is sitting on my spot, typing this.

    Xamarin.Auth team is consisted of 1 (one) person right now - and that is me. There are few people doing reviews, but no coding and no project management. I take all responsibility for management mistakes. I simply didn't have time to merge to master, update component, and implement everything. Xamarin.Auth is open sourced and anybody could do it. I jumped in voluntarily, because I thought it would be pity for that component to die.

    • 1.5.0 is out - with no extra new integration.
    • portable-bait-and-switch was merged to master
    • and yes - there is still a lot to do (docs, samples, new features, etc)

Answers

  • Richy_GeorgeRichy_George INMember ✭✭✭

    Hai, if you found another solution please post here.

  • EvgeniyZverevEvgeniyZverev USMember ✭✭

    Hi

    I just coded everything for Android (Chrome Custom Tabs) and iOS (SFSafariViewController) myself from scratch. For Windows I left it as it was, WebAuthenticationBroker seems to fit all the needs (I coded against it myself a year ago, Xamarin.Auth did not help here as well).

    Sad story...Xamarin.Auth is long dead.

    There is a live branch in the project that seems to be regularly updated which is hopelessly far from the master branch now. I do not know if anyone at Xamarin is actually watching the project right now.

    Regards,
    Eugene.

  • moljacmoljac HRBeta ✭✭✭

    @EvgeniyZverev

    A lot of criticism and bragging with a lot of false statements, but nothing constructive.

    Is anybody at Xamarin going to finally update the component?

    No. Until new features stabilize and new features are (very brief):

    1. Native UI support for Android (Custom Tabs) and iOS (SFSafariViewController)
    2. Xamarin.Forms support for everything (old + new AKA #1)

    The reason it took longer were

    1. some restrictions in Xamarin.Auth,
    2. desire not to break old API (or to break it minimally)
    3. add flexible API for new features

    I do not know if anyone at Xamarin is actually watching the project right now.

    Ask before jumping into false conclusions

    • here or
    • go to github and open issue,
    • send an email to Xamarin support,
    • go to community slack
    • XamarinHQ has facebook, twitter

    Sad story...Xamarin.Auth is long dead.

    Wrong. Check community slack and you will see 5+ success stories with Xamarin.Auth v >= 1.4.x.
    There is even demand from those users to add support for non-standard query parameters google introduced with this restriction.

    There is a live branch in the project that seems to be regularly updated which is hopelessly far from the
    master branch now.

    So, you checked github? How come it is dead? No commits on master means project is dead?
    Can you define "hopelessly far from the master branch" and explain what does that mean?

    I just coded everything for Android (Chrome Custom Tabs) and iOS (SFSafariViewController) myself from scratch.
    For Windows I left it as it was, WebAuthenticationBroker seems to fit all the needs (I coded against it myself a year ago, > Xamarin.Auth did not help here as well).

    Cool. I missed PR or link to the repo with permissive license.

  • moljacmoljac HRBeta ✭✭✭

    @EvgeniyZverev @Richy_George

    Xamarin community slack team and #xamarin-auth-social channel

    https://xamarinchat.slack.com/messages/C4TD1NHPT/

    Samples with highest update cadence (those are samples from Xamarin.Auth repo, but extracted for easier maintenace)

    https://github.com/moljac/Xamarin.Auth.Samples.NugetReferences

  • EvgeniyZverevEvgeniyZverev USMember ✭✭

    @moljac said:
    @EvgeniyZverev

    A lot of criticism and bragging with a lot of false statements, but nothing constructive.

    I pick up the gauntlet. Lets see.

    Is anybody at Xamarin going to finally update the component?

    No. Until new features stabilize and new features are (very brief):
    1. Native UI support for Android (Custom Tabs) and iOS (SFSafariViewController)

    The component is long since outdated. "New features" and chrome custom tabs in particular have nothing to do with this. To begin with the master branch does not support Windows 8.1, Windows Phone 8.1, UWP. Years passed. What "stabilization" are you talking about?? Google published chrome custom tabs api 2 YEARS!! ago. A few days ago Google blocked old API. It's time for the transition to FINISH, not begin. Don't be silly.

    1. Xamarin.Forms support for everything (old + new AKA #1)

    I do not actually understand what you are talking about here. Please be more specific. No sarcasm, I am really curious.

    The reason it took longer were
    1. some restrictions in Xamarin.Auth,

    What restrictions?

    1. desire not to break old API (or to break it minimally)

    Again. I do not understand what are you talking about. Appending NEW features utilizing Chrome Custom Tabs, SFSafariViewController and WebAuthenticationBroker have nothing to do with the old API.

    1. add flexible API for new features

    That's called expanding a library. When it lacks minimal vital functions...it's ridiculous.

    I do not know if anyone at Xamarin is actually watching the project right now.

    Ask before jumping into false conclusions

    • here or
    • go to github and open issue,
    • send an email to Xamarin support,
    • go to community slack
    • XamarinHQ has facebook, twitter

    Well, I do not pretend to ask everywhere I could. The facts are:
    1. Last Xamarin.Auth release (version 1.2.3.1) is January 12, 2015. More than 2 years ago. Is that component alive?
    2. Have a look at the component questions: https://components.xamarin.com/view/xamarin.auth Do you find many of them addressed? Still looks alive?
    3. Well...I asked here and several other xamarin forums. 2 months passed since a question got any attention. I do understand that not all questions can be answered. Still I see a problem here.

    Sad story...Xamarin.Auth is long dead.

    Wrong. Check community slack and you will see 5+ success stories with Xamarin.Auth v >= 1.4.x.
    There is even demand from those users to add support for non-standard query parameters google introduced with this restriction.

    To say the truth I do now know what "community slack" is. As for Xamarin.Auth v >= 1.4.x, it's not available for the general public since it is not published as a Xamarin Component release.

    There is a live branch in the project that seems to be regularly updated which is hopelessly far from the
    master branch now.

    So, you checked github? How come it is dead? No commits on master means project is dead?
    Can you define "hopelessly far from the master branch" and explain what does that mean?

    1. No commits on master means project is dead? Yes, exactly.
    2. "hopelessly far from the master branch" means it will hardly be ever merged into master. There is a chance it gets released as a new component or an incompatible new version requiring complete new integration. It should have been a year ago. Keeping the component aside from the master branch for 2 years actually means building up a new component in a hidden manner. It's the best way to hide one from public usage.

    I just coded everything for Android (Chrome Custom Tabs) and iOS (SFSafariViewController) myself from scratch.
    For Windows I left it as it was, WebAuthenticationBroker seems to fit all the needs (I coded against it myself a year ago, > Xamarin.Auth did not help here as well).

    Cool. I missed PR or link to the repo with permissive license.

    Do not compare a private project strictly limited to suit my local needs and restrictions with a publicly available library capable of surviving as a developer component. Cannot compare those. Mine required like 30 work hours. Yours requires another development skill level and thousands of work hours. What I meant to say here is that one in my place should not rely on Xamarin.Auth as an actual and supported component. It will be faster and easier to code against the Chrome Custom Tabs, SFSafariViewController and WebAuthenticationBroker myself. The implementation might be limited, but the alternative is to adopt unpublished Xamarin.Auth (non-master branch)...doubtful.

    Besides. I am not flaming Xamarin.Auth developers. I do not have a right to do so even if I stumble (which I did) at problems trying to use it. It was a great start for me to begin with when handling user authentication. My app suggests the user to authenticate against a dozen of OAuth2 providers including Microsoft, Google, Facebook Yandex, VK, Main.Ru, OK (last 4 are popular in Russia) and that became possible thanks to Xamarin.Auth as a source of sample code. I had to rework a lot but I had hot start. Xamarin.Auth developers, Thanks You!

    I am flaming Xamarin project administration for the lack of attention to that much needed component.

  • EvgeniyZverevEvgeniyZverev USMember ✭✭
    edited April 2017

    @moljac said:
    @EvgeniyZverev

    A lot of criticism and bragging with a lot of false statements, but nothing constructive.

    I pick up the gauntlet. Lets see.

    Is anybody at Xamarin going to finally update the component?

    No. Until new features stabilize and new features are (very brief):
    1. Native UI support for Android (Custom Tabs) and iOS (SFSafariViewController)

    The component is long since outdated. "New features" and chrome custom tabs in particular have nothing to do with this. To begin with the master branch does not support Windows 8.1, Windows Phone 8.1, UWP. Years passed. What "stabilization" are you talking about?? Google published chrome custom tabs api 2 YEARS!! ago. A few days ago Google blocked old API. It's time for the transition to FINISH, not begin. Don't be silly.

    1. Xamarin.Forms support for everything (old + new AKA #1)

    I do not actually understand what you are talking about here. Please be more specific. No sarcasm, I am really curious.

    The reason it took longer were
    1. some restrictions in Xamarin.Auth,

    What restrictions?

    1. desire not to break old API (or to break it minimally)

    Again. I do not understand what are you talking about. Appending NEW features utilizing Chrome Custom Tabs, SFSafariViewController and WebAuthenticationBroker have nothing to do with the old API.

    1. add flexible API for new features

    That's called expanding a library. When it lacks minimal vital functions...it's ridiculous.

    I do not know if anyone at Xamarin is actually watching the project right now.

    Ask before jumping into false conclusions

    • here or
    • go to github and open issue,
    • send an email to Xamarin support,
    • go to community slack
    • XamarinHQ has facebook, twitter

    Well, I do not pretend to ask everywhere I could. The facts are:
    1. Last Xamarin.Auth release (version 1.2.3.1) is January 12, 2015. More than 2 years ago. Is that component alive?
    2. Have a look at the component questions: https://components.xamarin.com/view/xamarin.auth Do you find many of them addressed? Still looks alive?
    3. Well...I asked here and several other xamarin forums. 2 months passed since a question got any attention. I do understand that not all questions can be answered. Still I see a problem here.

    Sad story...Xamarin.Auth is long dead.

    Wrong. Check community slack and you will see 5+ success stories with Xamarin.Auth v >= 1.4.x.
    There is even demand from those users to add support for non-standard query parameters google introduced with this restriction.

    To say the truth I do now know what "community slack" is. As for Xamarin.Auth v >= 1.4.x, it's not available for the general public since it is not published as a Xamarin Component release.

    There is a live branch in the project that seems to be regularly updated which is hopelessly far from the
    master branch now.

    So, you checked github? How come it is dead? No commits on master means project is dead?
    Can you define "hopelessly far from the master branch" and explain what does that mean?

    1. No commits on master means project is dead? Yes, exactly.
    2. "hopelessly far from the master branch" means it will hardly be ever merged into master. There is a chance it gets released as a new component or an incompatible new version requiring complete new integration. It should have been a year ago. Keeping the component aside from the master branch for 2 years actually means building up a new component in a hidden manner. It's the best way to hide one from public usage.

    I just coded everything for Android (Chrome Custom Tabs) and iOS (SFSafariViewController) myself from scratch.
    For Windows I left it as it was, WebAuthenticationBroker seems to fit all the needs (I coded against it myself a year ago, > Xamarin.Auth did not help here as well).

    Cool. I missed PR or link to the repo with permissive license.

    Do not compare my private restricted implementation which required like 30 work hours and a public developer component which requires a much higher skill level and a thousand of work hours. I do not pretend to to creating something useful for anyone but me and my customers here.

    Besides, I do not flame Xamarin.Auth developers. Xamarin.Auth enabled me to quickly get into the topic and create my own component with a hot start. Profit.

    I do flame Xamarin project administration for the lack of attention to this much needed component.

  • AhirAhir USMember ✭✭

    how to implement google login in Xamarin.forms (not in web view)

  • EvgeniyZverevEvgeniyZverev USMember ✭✭
    edited May 2017

    Here is a simplified instruction for Android platform:

    Reference the Xamarin.Android.Support.CustomTabs NuGet (version 23.3.0 at this moment).
    After your app startup but before the user is accessing the auth functionality, prepare the auth engine:

    //Save this reference at least at the class level. You will need it when the user actually tries to authenticate.
    CustomTabsActivityManager customTabsManager = new CustomTabsActivityManager(<reference to your main/current activity>);
    
    //Even if you get false, it will work, but probably with the fall-back to basic android browser.
    bool bound = customTabsManager.BindService();
    //Not sure what this returns.
    bool warmedUp = customTabsManager.Warmup();
    

    When user tries to authenticate you will need:

    CustomTabsIntent.Builder builder = new CustomTabsIntent.Builder();
    builder.EnableUrlBarHiding();
    builder.SetShowTitle(false);
    CustomTabsIntent customTabsIntent = clsBuilder.Build();
    customTabsIntent.Intent.SetFlags(ActivityFlags.NewTask);
    
    //Now the user will be taken away from your app (activity) to the browser and authentication.
    customTabsManager.LaunchUrl(<your start uri goes here>, clsCustomTabsIntent);
    

    Note that in the start uri you set your redirect uri which probably was something like urn:ietf:wg:oauth:2.0:oob:auto, now this has to change. Your new redirect uri has to be composed with your custom scheme and some path that helps you differentiate the calls to your activity, this will be covered later.

    For instance, my redirect uri is this: ru.noxx.polyglot16:/customtabs/oauth.

    Note that there is only one slash after the colon, this is not a typo:
    <custom scheme> :/ <arbitrary path>

    For the authentication results to get delivered to your app you will need to instruct the Android OS about something called custom uri scheme which is handled by your app:

    In your main activity definition, append the IntentFilter, my app's custom scheme is it's package name: ru.noxx.polyglot16. It is not all that arbitrary because Google authentication service will not accept any custom scheme. Your app's package name is one of those which are fine. Unique enough and readable enough.

        [Activity(
            Name = "...",
            MainLauncher = true,
            LaunchMode = LaunchMode.SingleTask,
            Theme = "...")]
        [IntentFilter(
        actions: new string[] 
        {
            Intent.ActionView
        },
        Categories = new []
        {
            Intent.CategoryDefault,
            Intent.CategoryBrowsable
        },
        DataScheme = "ru.noxx.polyglot16")]
        public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsApplicationActivity
        {
            ...
        }
    

    Note that I have the SingleTask Activity launch mode. I do not need the Android OS to launch another instance of my main activity when the user finishes with authentication (the browser redirects to the uri with my custom scheme).

    When the user gets through the authentication process, successful or unsuccessful, you need to be ready to process the results in your Activity code:

        //You get all the new Intents sent to your app here.
        protected override void OnNewIntent(Intent iNewIntent)
        {
            base.OnNewIntent(iNewIntent);
    
            if (iNewIntent != null)
            {
                //Save the reference to the newly obtained intent at class level;
                recentIntent = iNewIntent;
            }
        }
    
        //When your app is restarted, you need to check if you got a new intent with auth results.
        protected override void OnRestart()
        {
            base.OnRestart();
    
            //https://developer.android.com/reference/android/app/Activity.html#onNewIntent(android.content.Intent)
            if (recentIntent != null &&
                !string.IsNullOrWhiteSpace(recentIntent.DataString))
            {
                string activationData = recentIntent.DataString;
    
                if (Uri.IsWellFormedUriString(activationData, UriKind.Absolute))
                {
                    //Check the received activationData uri here. Be careful. You have to defend against brute-force and spoofing attacks here.
                }
            }
    
            //Don't forget to remember not to process the Intent more than once.
            recentIntent = null;
        }
    
  • moljacmoljac HRBeta ✭✭✭
    Accepted Answer

    Sorry for late response, but I had to finish few things 1st.

    @EvgeniyZverev said:

    @moljac said:
    @EvgeniyZverev

    Is anybody at Xamarin going to finally update the component?

    No. Until new features stabilize and new features are (very brief):
    1. Native UI support for Android (Custom Tabs) and iOS (SFSafariViewController)

    The component is long since outdated. "New features" and chrome custom tabs in particular have nothing to do with this.

    Have you ever written/implemented/packaged Xamarin.Component?
    I did. Quite a few. Component requires samples for each supported platform, docs and artwork. And this is quite substantial effort. Initial Xamarin.Auth team is partially on Xamarin.Forms team and some left Xamarin.

    To begin with the master branch does not support Windows 8.1, Windows Phone 8.1, UWP. Years passed.

    Windows Phone, WinRT support was added in early 2016. It was in nuget version 1.3.x for Evolve16 (2016-04-2x).

    What "stabilization" are you talking about??

    To enable some OAuth features that were not in present Xamarin.Auth like:

    • custom schemes,
    • different host support (localhost)
    • Native UI (with low level API support)
    • WKwebView support (in addition to UIWebView)

    a lot of refactoring was necessary.

    Very few sane people would expect no problems after such refactoring on existing codebase. Fixing those issue was meant under "stabilisation".

    Google published chrome custom tabs api 2 YEARS!! ago. A few days ago Google blocked old API. It's time for the transition to FINISH, not begin.

    The component is outdated, but the library itself was not. Simple peek into activity on GitHub and nuget would reveal that. We would be very happy with your PR with CustomTabs 2 years ago.

    FYI google announced ban for Embedded WebViews in 2016-08 and this is less than 2 years.

    Xamarin.Auth v.1.4.0 with first implementation of Native UI was published on 2017-03-30, before google's deadline. Quie a few people managed to implement OAuth with NativeUI before the deadline.

    Don't be silly.

    Nice.

    1. Xamarin.Forms support for everything (old + new AKA #1)

    I do not actually understand what you are talking about here. Please be more specific. No sarcasm, I am really curious.

    Version 1.4.0 was pushed before google's deadline, so the people could implement OAuth with Native UI, before deadline. Estimation was that 3 weeks (20 days) should be enough to do it. API refactoring was far from ideal, but 1.4.x came out. Then stabilized and switched to 1.5.0-alpha- with Xamarin.Forms support, because the pressure was to high and writing Custom Renderers was complicated.

    The reason it took longer were
    1. some restrictions in Xamarin.Auth,

    What restrictions?

    Xamarin.Auth never supported custom schemes. Never supported localhost or similar. When Authenticator constructor is created first request is already sent to the OAuth provider. It was necessary to "fit into old API" - that was design goal for new API.

    1. desire not to break old API (or to break it minimally)

    Again. I do not understand what are you talking about. Appending NEW features utilizing Chrome Custom Tabs, SFSafariViewController and WebAuthenticationBroker have nothing to do with the old API.

    It has. GetUI() returns login screen and a lot happens behind it.

    1. add flexible API for new features

    That's called expanding a library. When it lacks minimal vital functions...it's ridiculous.

    Maybe.

    I do not know if anyone at Xamarin is actually watching the project right now.

    Yes.

    Ask before jumping into false conclusions

    • here or
    • go to github and open issue,
    • send an email to Xamarin support,
    • go to community slack
    • XamarinHQ has facebook, twitter

    Well, I do not pretend to ask everywhere I could. The facts are:
    1. Last Xamarin.Auth release (version 1.2.3.1) is January 12, 2015. More than 2 years ago. Is that component alive?

    Define alive.

    It can still be used with most of the OAuth providers. Even with google, but the question is when will google cut it off.

    1. Have a look at the component questions: https://components.xamarin.com/view/xamarin.auth Do you find many of them addressed? Still looks alive?

    I'm aware of those comments. The problem is it is impossible to reply to those comments in the comment area, only by mail and that helps a little, because people simply do not check other sources of information (github, nuget, forums, community slack channel).

    1. Well...I asked here and several other xamarin forums. 2 months passed since a question got any attention.

    The problem is/was lack of time and daily tasks with higher priorities.

    I do understand that not all questions can be answered. Still I see a problem here.

    Sad story...Xamarin.Auth is long dead.

    This is your opinion. I'm happy there is a lot of people with different opinion.

    Here is pinned item on 2017-05-01

    https://xamarinchat.slack.com/archives/C4TD1NHPT/p1493666223953008

    You will not be able to see it, because of limited history for community slack channel, but here is the blog:

    https://subhamoyburman.wordpress.com/2017/05/01/google-oauth-xamarin-auth-ios-implementation-with-custom-tabssafaricontroller/

    So, 10 days after google's deadline people were able to blog about Xamarin.Auth Native UI support.

    Wrong. Check community slack and you will see 5+ success stories with Xamarin.Auth v >= 1.4.x.
    There is even demand from those users to add support for non-standard query parameters google introduced with this restriction.

    To say the truth I do now know what "community slack" is.

    Community slack is public slack team organised by community and joined by vaste majority of Xamarin engineering team to help users out.

    As for Xamarin.Auth v >= 1.4.x, it's not available for the general public since it is not published as a Xamarin Component release.

    Not having component does not mean that some SDK is not available for general public. Most of the SDK 3rd party vendors decide not to package component. Component is guarantee for those using it, that it is curated and safe. It provides samples and docs. Some components wrap nugets.

    https://developer.xamarin.com/guides/cross-platform/advanced/submitting_components/components_and_nuget/

    So, most developers push nugets first before going (if at all) for components. And this is the case with Xamarin.Auth.

    There is a live branch in the project that seems to be regularly updated which is hopelessly far from the
    master branch now.

    So, you checked github? How come it is dead? No commits on master means project is dead?
    Can you define "hopelessly far from the master branch" and explain what does that mean?

    1. No commits on master means project is dead? Yes, exactly.

    OK. This might be rule in your organisation. Xamarin recently introduced similar rule that master must be releasable. Still I know projects where this is not the rule.

    1. "hopelessly far from the master branch" means it will hardly be ever merged into master.

    I will have to disappoint you. It was merged.

    There is a chance it gets released as a new component or an incompatible new version

    Only your opinion and not based on facts. (See facts about API and stabilisation above)

    requiring complete new integration.

    Right now 20+ people needed no new integration.

    It should have been a year ago.

    I wish it too.

    Keeping the component aside from the master branch for 2 years actually means building up a new component in a hidden manner. It's the best way to hide one from public usage.

    Seems like you were the only one that was not able to "find it".

    I just coded everything for Android (Chrome Custom Tabs) and iOS (SFSafariViewController) myself from scratch.
    For Windows I left it as it was, WebAuthenticationBroker seems to fit all the needs (I coded against it myself a year ago, > Xamarin.Auth did not help here as well).

    Cool. I missed PR or link to the repo with permissive license.

    Do not compare my private restricted implementation which required like 30 work hours and a public developer
    component which requires a much higher skill level and a thousand of work hours.

    It was several hundreds of hours (with porting Google team's samples and preparing some other utilities).

    I do not pretend to to creating something useful for anyone but me and my customers here.

    OK. Finally agreeing.

    Besides, I do not flame Xamarin.Auth developers.

    Yes you do - believe me.

    Xamarin.Auth enabled me to quickly get into the topic and create my own component with a hot start. Profit.

    I'm glad to hear that.

    I do flame Xamarin project administration for the lack of attention to this much needed component.

    Cool.

    I will escalate your issue to Xamarin.Auth project administration right now of speaking, because project manager is sitting on my spot, typing this.

    Xamarin.Auth team is consisted of 1 (one) person right now - and that is me. There are few people doing reviews, but no coding and no project management. I take all responsibility for management mistakes. I simply didn't have time to merge to master, update component, and implement everything. Xamarin.Auth is open sourced and anybody could do it. I jumped in voluntarily, because I thought it would be pity for that component to die.

    • 1.5.0 is out - with no extra new integration.
    • portable-bait-and-switch was merged to master
    • and yes - there is still a lot to do (docs, samples, new features, etc)
  • EvgeniyZverevEvgeniyZverev USMember ✭✭
    edited May 2017

    Have you ever written/implemented/packaged Xamarin.Component?

    No, I didn't.

    I did. Quite a few. Component requires samples for each supported platform, docs and artwork. And this is quite substantial effort. Initial Xamarin.Auth team is partially on Xamarin.Forms team and some left Xamarin.

    That's what I figured out and meant to note saying "I am flaming Xamarin administration for the lack of attention to Xamarin.Auth".

    Windows Phone, WinRT support was added in early 2016. It was in nuget version 1.3.x for Evolve16 (2016-04-2x).

    Since wrapping newer Xamarin.Auth NuGet releases into a Xamarin.Component is a problem, why not mark the Xamarin.Auth component as outdated with proper links to the actual github branch and slack?

    Very few sane people would expect no problems after such refactoring on existing codebase. Fixing those issue was meant under "stabilisation".

    Now I get you were talking about the Xamarin.Component release problems.

    The component is outdated, but the library itself was not. Simple peek into activity on GitHub and nuget would reveal that. We would be very happy with your PR with CustomTabs 2 years ago.

    Again, I was thinking that Xamarin.Component lifecycle is matching the library. Apparently I was wrong. As for my PR, I am not into opensource development yet and I am not happy about it. But that's what I have to deal with.

    FYI google announced ban for Embedded WebViews in 2016-08 and this is less than 2 years.

    Mentioning "2 years" I was speaking about the API release, not the ban announcement.

    Xamarin.Auth v.1.4.0 with first implementation of Native UI was published on 2017-03-30, before google's deadline. Quie a few people managed to implement OAuth with NativeUI before the deadline.

    My initial question was posted on 2017-02-12, obviously before the release of Xamarin.Auth v.1.4.0. To say the truth I completely missed that the NuGet was reanimated by that moment.

    Look at this gap:
    Xamarin.Auth 1.3.2-alpha-03 274 Sunday, January 8, 2017
    Xamarin.Auth 1.3.2-alpha-01 2,200 Wednesday, August 17, 2016

    Somewhere in between I myself decided I need custom implementation of all the features I need and miss in the component.

    At the moment I made the post, quite a few release versions of the NuGet were released and I should have checked that. But I only checked that there were no new releases of the component. My bad.

    Don't be silly.

    Nice.

    That's out of context here. Anyway, I am sorry for the swearing. I should have restrained myself.

    Xamarin.Auth never supported custom schemes. Never supported localhost or similar. When Authenticator constructor is created first request is already sent to the OAuth provider. It was necessary to "fit into old API" - that was design goal for new API.

    1. desire not to break old API (or to break it minimally)

    Again. I do not understand what are you talking about. Appending NEW features utilizing Chrome Custom Tabs, SFSafariViewController and WebAuthenticationBroker have nothing to do with the old API.

    It has. GetUI() returns login screen and a lot happens behind it.

    I do not get the last remark concerning the link between the GetUI() and Chrome Custom Tabs, SFSafariViewController and WebAuthenticationBroker. I think I need to have a look at the new Xamarin.Auth here. Please do not waste more time on this point.

    I do not know if anyone at Xamarin is actually watching the project right now.

    Yes.

    Well, for me that's great news!

    Define alive.

    An opensource library can be called perfectly alive if it is released at least once a month and there are no "outdated" pull requests for the master branch. I call a pull request "outdated" when it is not reviewed for more than two releases. A reviewed pull request can be held off for a while i.e. conserved. Ideal situations only exist in our imagination, that's true. But the farther I wander from it the closer I am to be referred to as dead.

    I'm aware of those comments. The problem is it is impossible to reply to those comments in the comment area, only by mail and that helps a little, because people simply do not check other sources of information (github, nuget, forums, community slack channel).

    I addressed that earlier. Why not edit the component description?

    https://subhamoyburman.wordpress.com/2017/05/01/google-oauth-xamarin-auth-ios-implementation-with-custom-tabssafaricontroller/

    So, 10 days after google's deadline people were able to blog about Xamarin.Auth Native UI support.

    OK, do you mean to say that the aspect of "informational support" for the Xamarin.Auth life cycle is just fine?

    Community slack is public slack team organised by community and joined by vaste majority of Xamarin engineering team to help users out.

    Thanks, subscribed.

    So, most developers push nugets first before going (if at all) for components. And this is the case with Xamarin.Auth.

    I guess I will just have to live with that.

    I will have to disappoint you. It was merged.

    Yay! You can never disappoint me with that. You did prove me wrong here and that's a real inspiration. I will be happy to switch back to Xamarin.Auth as soon as I can if only I will be able to.

    Right now 20+ people needed no new integration.

    I will give this a try for sure.

    Seems like you were the only one that was not able to "find it".

    How about those comments at the Xamarin.Auth component? What about all those pull requests waiting for years at the Xamarin.Auth nuget master? Was that me who posted them all?

    Besides, I do not flame Xamarin.Auth developers.

    Yes you do - believe me.

    Since you are and the only Xamarin.Auth developer and you state that I hurt your feelings with my remarks there is a thing I find constructive to answer. I am sorry. I apologize for being unnecessarily rude. I will try to avoid that altogether in the future.

    I will escalate your issue to Xamarin.Auth project administration right now of speaking, because project manager is sitting on my spot, typing this.

    Xamarin.Auth team is consisted of 1 (one) person right now - and that is me. There are few people doing reviews, but no coding and no project management. I take all responsibility for management mistakes. I simply didn't have time to merge to master, update component, and implement everything. Xamarin.Auth is open sourced and anybody could do it. I jumped in voluntarily, because I thought it would be pity for that component to die.

    • 1.5.0 is out - with no extra new integration.
    • portable-bait-and-switch was merged to master
    • and yes - there is still a lot to do (docs, samples, new features, etc)

    All in all you gave me the new hope and actually great news. Thanks you.

Sign In or Register to comment.