I had been working on dropbox enabling an application and when the person elected to connect to Dropbox, the authentication process launched an intent within the app, once the window popped I was able to accept the access and the app resumed as usual and everything was great.
Something changed when I turned the code over for implementation such that now when I elect to connect to Dropbox, the app instead launches a webpage for authentication instead of the intent. Also, the "resume" is not called in the application after I authorize the app to dropbox.
I have looked in the usual places but have been unable to determine why this has changed.. Thoughts??
Did you recently pick up an updated version of the Dropbox SDK? There was a recent update which uses an improved authorization flow. If your app is using the new flow, and you don't yet have a version of the Dropbox Android app which supports that flow, then your API app will fall back to using browser-based authorization. This should go away once the Dropbox Android app is updated in Google Play.
The web-auth flow should still return control to your app in the same way as the delegated-auth flow. If you're seeing issues there, you should get in touch with Dropbox support. You can submit a ticket using the "API Support" link on dropbox.com/developers
Related
I have an angular/ionic website that has registration, login, and dashboard pages. I want to build an android & ios app with the same code base.
When users download the app from the play store, if I add a new page/make a change to the existing page I have to submit the app for review, and then it will show the option for the update. Also, the user may not update the app. I want to show the latest changes to users as soon as I am ready with the update.
To achieve this I have followed the below steps:
1.I have built and deployed a web app(without native code). Let's call it xyz.com
2.I created a new ionic project for the APK file. I have placed an iframe with src=xyz.com
When I take the APK build of a new project, because of the iframe tag I can see the complete web app loaded. Whenever I make changes to the main web app project, after deploying to xyz.com just reopening the mobile app I can see the latest changes.
3.I have to read OTP during user login. So, after validation of user credentials in the web app, the next step is to enter the OTP. Now I have sent the event from the web app to the parent window(mobile app) like this:
window.parent.postMessage('ReadSMS','*')
In the mobile app, I listened to events from the website loaded in iframe like this:
window.addEventListener('message', handleMessage, false);
function handleMessage(event) {
if(event.data === 'ReadSMS'){
// Start native plugin cordova-plugin-sms-receive to read incoming sms
// After reading the SMS it is sent to the web app(in iframe)
myIframe.contentWindow.postMessage('SMSResult', '*',{OTP:otpfromsms});
}
}
In the web app, I listen to the events sent from the mobile app and auto-populate the OTP in the input box.
With the above iframe approach, users can use the new pages/bug fixes without updating the mobile app from the play store.
Since I use very less native plugins and they are not changed frequently. If I make any native code changes, then users have to update the app from play store, I am ok with that.
We have a tool called Ionic Appflow which has Live Update feature lets you update the UI and business logic of your app remotely, in real-time. Push HTML, JS, and CSS updates directly to your users without going through the app store to instantly fix bugs and ship new features.
The ionic Appflows is a paid tool and we can't afford it. However, I'm able to achieve live update feature and native functionality with just iframe and window message events.
Is there any disadvantage in the approach I have taken? Will, there be a problem while getting approval for listing my mobile app in the android play store and ios app store?
Can somebody please tell me the cons of the approach I have followed.
Thank You
I'm currently running into an issue with steps to reproduce this bug as follows:
Install the app
Login with Facebook
Uninstall the app
Reinstall the app using the same apk
Logout of Facebook and into a different Facebook account
Open the app and login with Facebook
Should see the old user account being logged in automatically
instead of asking to create a new user account, or logging into a
different account.
The only fix I've seen for this issue so far is to delete all the app data on the device (or at least the cache), which clears this issue. It appears that the Android OS is holding on to cache even after the app is uninstalled. I'm wondering if there's a way to fix this in my app by clearing the Facebook data on startup. Unfortunately I can't find a way in the Facebook API to do this, unless I'm missing something. We have the concept of a guest user in our app, so ideally I can detect if it's a guest user and delete all previous Facebook data on startup.
For more information: This is a Unity Android application using the Facebook Graph API
The code works properly from dev portal of microsoft. But can anyone please tell me how it should behave in following use case
Consider two apps: App1 and App2
I have developed same code and installed both apps simultaneously
App1 as launched first will ask me credentials for the webview. Thats fine. as I have not cache or already logged in till date.
Once I log in successfully, The apps works properly as auto login
Now when I open App2, it still throws me Login page. Ideally it should take cache of App1 and auto login.
Please note: I have provided same 'shared id' in both apps in manifest
Please let me know about thus as i am stuck with internal Single Sign on issue since long
I see you have tagged the question with ADAL, so I'll assume that's the library you're using. ADAL uses webviews to prompt for sign in. Webviews in Android do not share much state between apps, and are pretty much completely sandboxes (isolated and do not share session cookies, etc).
Now, you most definitely can achieve SSO for Android using ADAL, you have 2 options:
Brokered SSO
Using a broker application, like the Microsoft Authenticator, the end user basically signs in here such that they're able to maintain a session inside the Broker's sandbox. This allows any app that signs in Azure AD users to share state. The article linked above explains how to enable your app to use the broker.
Non-Brokered SSO
You can configure SSO between all of the apps you own. This means an end user will get SSO between App 1, App 2, App N, but not necessarily another App in the Azure AD ecosystem. The article linked above explains how to enable your app to use non-brokered SSO.
Bonus Option: v2 with MSAL
I said earlier ADAL uses webviews for sign in, there's another way to do it that the Microsoft Authentication Library (MSAL) supports using the system's browser. Quite simply, this uses the Chrome or a Chrome custom tab browser on the device rather than the in-app webview. Then, the session cookie is set on the global browser so any app that also uses the browser (or if the end user has used the browser natively to sign in) will get SSO. The stipulation here is MSAL works against the Azure AD v2.0 endpoint which has some limitations, but also supports some sign in with Microsoft Accounts (*.outlook, *.live, etc) out of the box.
If you're interested in trying v2 + MSAL, I recommend trying the Android Guided Walkthrough which walks you through how to build an app that calls the Microsoft Graph.
Google's decision to disallow oauth via webview is causing me huge amounts of trouble. It's been a long and difficult process migrating to an alternative (I'm using the suggested AppAuth library at the moment) and I'm getting user complaints about not being able to link accounts without also adding them to chrome/their device (which as far as I can tell is now impossible without somehow forcing a private browsing session). My latest problem involves google oauth to sign into another service. Here's the scenario:
A user wants to link a 3rd party service to my application. Their account on the third party service is linked to a google account. To auth with this third party service, they must sign into their google account. The problem is that the 3rd party service only allows http:// scheme redirect URI's for their oauth, so the flow looks something like this:
User is in my app on their android device
User clicks a button to link their thirdparty account with my app
Using the appauth library, I launch a browser or custom tab with the oauth URL's for the 3rd party, let's just call it http://thirdparty.com/oauth
From that page, the user clicks a "sign in to google" button, which triggers the google oauth flow, which they then follow to provide their google account token to thirdparty
User approves access to my app with thirdparty now that thirdparty has validated their google account
thirdparty redirects to the registered redirect_uri which is then opened in the browser tab instead of redirecting back to my application.
The problem is step 6 here. Because I am required to register an http:// scheme redirect URI, the browser tab attempts to load the webpage directly, even if I have registered my app to handle that particular url. Now if it wasn't required for users to be able to sign in with google, I could easily just do this whole flow in a webview and manually trap the redirect, grabbing the token, but because thirdparty allows users to link their google account, I can't use a webview because google will block users from performing google auth in a webview, so I am forced to pass off to an app or browser tab that I don't have control over and am dependent on that behaving properly (which it often doesn't)
I did plenty of searching and it looks like App Links would solve my problem by registering my app as the primary handler for a link, but that only works in Android 6.0+, which is higher than my device minimum, so I'm at a loss as to what I'm supposed to do here.
My constraints are:
oauth redirect must be an HTTP scheme (required by thirdparty)
I cannot auth in a webview (required by google)
I need my auth redirect to launch my application in order to collect the token
I need the solution to work for all devices on android 5.0+
I have not found a single solution to this problem through hours of searching, and I have found no way to get in touch with the google oauth team to learn what their suggestions are.
Has anyone found a way to do have an http:// link launch an application without prompting the user and without requiring android 6.0?
If you have control over the redirect URI, you can set your application to listen for it using a custom Intent Handler. This is essentially a form of Deep Linking, and should work with Android 5+, (in 6 you can even set your app as the default!).
For the data, you will most likely need to use the URI itself. But that shouldn't be too hard assuming you have control of the re-direct.
I'm trying to have my App upload a file on Dropbox and I downloaded their DBRoulette test program but I found also there the strange behavior I'm now gonna explain
Basically once you push the button for authenticating the App and authorize it to link with your Dropbox there's a command the library provides which is
private DropboxAPI mApi;
mApi.getSession().startAuthentication(context);
Once this command is processed the native browser opens and shows the buttons Deny or Allow to accept or not the authorization, but the problem is that when you press it, the App comes back and shows itself while the native browser lies in the background, ready to appear again once you exit from the app and this is rather annoying (though it does it only the first time you launch the app)
p.s. before I forget I DO use in the onResume the following code which is suggested in the tutorial
session.finishAuthentication();
Thanks to anyone who will help me understand this problem better and (hopefully) solve it redirecting the authorization in a Webview OR closing the native browser once the button is pressed and the authentication is processed
Unfortunately, there is not much you can do about it.
The authentication process runs on the server-side, i.e. on Dropbox. That means that Dropbox defines the course of action for authenticating a user which you as the client have to follow. That's part of the idea of the OAuth authentication flow.
What I have experienced myself though is the fact that if you have the official Dropbox app installed, the app is used for authenticating the user (instead of the browser) and also gets closed after the user has pressed the allow/cancel button.