Dropbox.js authentication in Cordova/PhoneGap - javascript

I'm writing an app in Cordova/PhoneGap which tries to fetch a file from Dropbox using Dropbox.js. Cordova version is 3.0.1 and Dropbox.js version is 0.10.0. My Javascript works just fine on a desktop browser with this:
var client = new Dropbox.Client({ key: "<my key>", secret: "<my secret>"} );
client.authenticate(function(error, client) {
...
But in the Cordova-packaged app I get an error: "It seems the app you were using submitted a bad request".
I suspect the problem has to do with the redirect-url which resolves to this in the Cordova app:
Dropbox.AuthDriver.BrowserBase.currentLocation()
-> file:///android_asset/www/index.html
Urls starting with file:/// will not work properly with Dropbox API even if I add them to OAuth redirect URIs in Dropbox API console.
The Cordova app does work fine if I know the uid and token before:
var client = new Dropbox.Client({
key: "<my key",
secret: "<my secret>",
token: "<token>",
uid: "<uid>"
});
client.authenticate(function(error, client) {
...
This way I can read my dropbox files just fine. Problem is that the token doesn't last forever and I 'd like to get a new one from my app itself.
According to this discussion, this issue should already have been resolved in an earlier version of dropbox.js (0.9.2). But I still run into it. I wonder if I should use the API a bit differently, but I don't know how.
Dropbox.js has added a redirectUrl option in this commit I just don't know exactly what should I put there in my Cordova app. The file:///android_asset/www/index.html will not work because Dropbox API does not allow file urls.
Simon McDonald's answer to this question might help. But that means I have to have an external server-hosted page with the dropbox.js login functionality. Or could I use the main dropbox web login page instead?

dropbox.js 0.10.1 has some fixes for Cordova.
We have just set up a page that you can use as the OAuth 2 redirect URL in embedded WebViews, when file:// doesn't work.
https://www.dropbox.com/1/oauth2/redirect_receiver

Related

Google Auth OAuth 2.0 SvelteKit wierd behavior

I am using Google Auth OAuth 2.0 One Tap Sign and Sveltekit,
and I got some really weird behavior,
I followed this doc https://developers.google.com/identity/gsi/web/guides/overview with javascript
onMount(async () => {
const handleCredentialResponse = async (response) => {
console.log('Encoded JWT ID token: ' + response.credential);
};
google.accounts.id.initialize({
client_id: clientId,
callback: handleCredentialResponse,
});
google.accounts.id.renderButton(
document.getElementById('buttonDiv'),
{ theme: 'outline', size: 'large' } // customization attributes
);
google.accounts.id.prompt();
});
the code from the doc.
Sometimes it works everything goes well,
Sometimes I got
Uncaught (in promise) ReferenceError: google is not defined
And some mobile / mobile browsers I get
[GSI_LOGGER]: The given origin is not allowed for the given client ID.
but works on laptop
Hope someone can understand and help.
Do we have any way to check logs for investigation?
I got your code to successfully run without modification: https://google-signin-kit.vercel.app/ (This app is in "dev" mode so signin may only succeed with my Google account. If you clone my repo and set your Google client id, signin will work for you.)
I would check how my code is different from your code outside onMount(). For example, how did you include the Google javascript? I describe one major change below.
You also need to check your Google app settings. [GSI_LOGGER]: The given origin is not allowed... is fixed by adding the HTTPS app domain to your Google app "Authorized JavaScript origins." Non-HTTPS domains are not allowed. For example, these domains would not work:
https://google-signin-kit-leftium.vercel.app/ (Not added as Authorized JavaScript origin)
http://google-signin-kit.vercel.app/ (Not HTTPS, if Vercel did not automatically redirect to HTTPS)
Of course, raw IP addresses will not work, either.
localhost is a special exception, but not easy (impossible?) to access from mobile.
ReferenceError: google is not defined (sometimes) happens because onMount() runs before the Google script is loaded.
To get a consistent reproduction, USB debug/inspect Android Chrome and set "disable caching" and throttling to "Slow 3G." (I could not reproduce on desktop Chrome).
Fixed by removing defer async when including Google's script: <script src="https://accounts.google.com/gsi/client"></script>
It should also be possible to call a function after the script is loaded, but I got inconsistent results in SvelteKit. For some reason Kit doesn't always call the load function. Possibly a bug?
Ideally, the Google script should be imported, but I couldn't find a version of the Google script that was built for importing. You may be able to construct a library that you can import? Importing would compile the Google script code into your app, tree-shaking the unused portions. Thus saving a network request and bandwidth.
Another workaround is to have your onMount function check for the google variable. If google is still undefined, call your function again after a certain timeout.

Silent Renewal in Ionic 3 with Identity Server 4

So I am trying to implement silent renewal in an ionic 3 application, I am still learning about the whole thing so I'll try to be as descriptive as possible please correct me if I am wrong.
Authentication
I am using Implicit flow for my authentication using the In App Browser.
The user is redirected to the authentication server page
After a success authentication I retrieve the id-token & access-token
As I understand the id-token is for authentication and access-token is for authorization with the API.
I have followed this article to help me set this up (Particularly the "Deploy to Mobile Device" section) for my Identity Server.
As done in the article I am using angular-oauth2-oidc to assist me with storing information about redirect links, issuer, etc...
I have attempted to achieve this in 3 different ways, 2 of them work but I don't understand how to retrieve the new access-token and id-token, and the last one returns an error. each of them left me with questions.
First: oauthService
The angular-oauth2-oidc library has a silentRefresh() method, and this github MD describes how to use it using a hidden iframe very vaguely so I barely understand how this works. I have created a silent-refresh.html page in the same directory, but using http://localhost:8000/silent-refresh.html return's a 404. Calling the silentRefresh() method successfully re-authenticates on the server side but the request times-out on the client side, as said in the MD file, something is wrong with the iframe.
Question 1: Does the library create a new iframe and then waits for a response to the http://localhost:8000/silent-refresh.html page but is never found so I never get my response? How to proceed to retrieve my tokens?
Second: iframe
So here I follow this article where I create an iframe and add it to the body. I create my own url (similar to the one made by the silentRefresh() method), and assign it to the src of the iframe. Again on the server side everything is fine and it tries to return the tokens to http://localhost:8000.
public startRenew(url: string) {
this._sessionIframe.src = url;
return new Promise((resolve) => {
this._sessionIframe.onload = () => {
resolve();
}
});
}
Question 2: How to proceed to retrieve the tokens? as it doesn't update my tokens automatically, and I don't see how the code above can do it.
Third: In App Browser
I thought this would work fine as I already know how to process the request using the In App Browser. So I tried to use the same url that worked for the iframe in the 2nd part. However this returns an error: prompt=none was requested. But user is not authenticated. on the server side, which tells that the server can't find the session so it doesn't know who is requesting the token renewal.
Question 3: Is there a specific reason this won't work other than I made a mistake?
NOTE: Took longer than expected to write this will edit this in a bit.
oAuthService
So I looked in to the implementation of the silent refresh, to see what it does. It creates an iframe with a default id, unless you override it. That cleared up a lot of confusion as to what was actually happening.
The next mistake I did was placing the silent-refresh.html file in the src/ folder, that makes it inaccessible to the iframe. Instead the file should have been placed in the www/ folder.
Then inside the iframe I kept getting the net::ERR_CONNECTION_REFUSED error. This was due to CORS and is solved by editing the Client int the Config.cs file on the Authentication Server:
AllowedCorsOrigins = { "http://localhost:8100", "http://<ip>:8100/", "http://<ip>:8100/silent-refresh.html" },
WARNING: This didn't work once I wanted to take this outside serving in the browser (ionic serve) or emulating on my device with ionic cordova run android -c-l-s, these made the root url return something like http://<ip>/. But once ran with ionic cordova run android (without the flags), window.location.href would return file:///<example>/<something>/index.html, using this sort of path (file:///<example>/<something>/silent-refresh.html) as a redirect url caused an ERR_UNSAFE_REDIRECT error to display in the iframe.
Perhaps silentRefresh() is an Angular only solution?
In App Browser
The mistake that caused the original error was having clearsessioncache and clearcache set to yes when creating the browser, caused the session to be wiped so the authentication server didn't know who it was duh, now reduced to this:
const browser = window.cordova.InAppBrowser.open(oauthUrl, '_blank',
'location=no, hidden=yes'
);
Regular redirect url of http://localhost:8100 could be used to catch the request with the new tokens. And the silent-refresh.html page is not needed.
Here is the code for creating the oauthUrl:
buildOAuthRefreshUrl(nonce): string {
return this.oauthService.issuer + '/connect/authorize?' +
'response_type=id_token%20token' +
'&client_id=' + this.oauthService.clientId +
'&state=' + nonce +
'&redirect_uri=' + encodeURIComponent(this.oauthService.redirectUri) +
'&scope=' + encodeURI(this.oauthService.scope) +
'&nonce=' + nonce +
'&prompt=none';
}
The rest of the code is pretty much identical to the originally mentioned article

Meteor android app not showing images

I am using the excellent file-collection package,
https://atmospherejs.com/vsivsi/file-collection
to store images in my Mongo database. Running the app on Android doesn't show the images (they appear as broken images). In the browser it is perfect.
I don't think the problem is unique to this package, as it is using Mongo's gridfs to store the images, and provides URL's to access them.
Here is a note from Vaughn in the documentation:
Cordova Android Bug with Meteor 1.2+
Due to a bug in the Cordova Android version that is used with Meteor
1.2, you will need to add the following to your mobile-config.js or you will have problems with this package on Android devices:
App.accessRule("blob:*");
Which I have done, but without success.
I also see the documentation references setting headers to deal with CORS issues, like this:
myFiles = new FileCollection('myFiles',
{ resumable: true, // Enable built-in resumable.js chunked upload support
http: [ // Define HTTP route
{ method: 'get', // Enable a GET endpoint
path: '/:md5', // this will be at route "/gridfs/myFiles/:md5"
lookup: function (params, query) { // uses express style url params
return { md5: params.md5 }; // a query mapping url to myFiles
},
handler: function (req, res, next) {
if (req.headers && req.headers.origin) {
res.setHeader('Access-Control-Allow-Origin', 'http://meteor.local'); // For Cordova
res.setHeader('Access-Control-Allow-Credentials', true);
}
next();
}
},
But again without success.
Looking at the network tab on the inspector, I can't even see requests for the images from the server, which suggests that it is being denied by something in the Cordova code, and it's not even trying to go out and get the images.
I have reproduced the problem using Vaughn's demo app, which I have forked and added the android platform, so it's ready to go if you care to try and help.
https://github.com/mikkelking/meteor-file-sample-app
If you do a meteor run android-device it should run on the Android. You will need to register and then upload an image to see the problem. From a browser it works fine.
Any help would be appreciated, this is a show stopper for my project. One option I have considered is to move the images to an S3 bucket, which I think should work, but I'd like to keep the images in the db if I can.
I had a similar issue once with gridfs. I believe that the issue comes because the image source is a relative source. So your image sources are coming from localhost. It works on the web version because the browser is on the same machine as your server, so a localhost source works fine. But on the android device it won't work because the images are not served on that device.
When I had this problem I just deployed to production and it worked on mobile devices because the image source pointed to a url that was on the internet and not relative to the device. This works for production but not for dev testing.
When I saw this question I cloned your code and got it working on an android device for local dev.
The first step I did is to set the ROOT_URL env variable and mobile server to point to the your local server. When you run meteor locally you can run a command like this to set these variables, using your computer's local ip address
export ROOT_URL=http://192.168.1.255:3000 && meteor run android-device --mobile-server=http://192.168.1.255:3000
Next, in your sample.coffee Template.collTest.helpers link function, you need to use the absolute url instead of a relative one (so that on your mobile device it will look to your local server instead of localhost). To dynamically get this so that it works on different servers, you can use something like this
Meteor.absoluteUrl(myData.baseURL + "/md5/" + this.md5)
Then I had to add the computer's ip address http://192.168.1.255:3000 to the content security policies in the sample.jade file.
I almost forgot, at this point I was getting a 403 forbidden error. I changed the myData.allow read function in sample.coffee and just returned true and the 403 was gone, something was happening with the permissions there
After that the image showed up on my android device.

API calls are not working in cordova application

I made an application using apache cordova. my server is written in node.js running locally and port 3005. So I want to make API call from cordova I am using backbone in client side.
I written the following code to make API call
makingAPICallForStatus:function(){
var userSessionModel = Backbone.Model.extend({ //Creaating a model for checking user session status
url:"http://localhost:3005/api/user/status/",
});
var userSessionModelObj=new userSessionModel();
this.makeApiCall(userSessionModelObj,"",'GET',function(model,response,options){console.log(response);});
},
makeApiCall:function(modelObj,dataObject,requestType,successCallback){
modelObj.fetch({data:dataObject,
type:requestType,
success:successCallback,
error:function(){console.log("error")}
});
}
If you observe, I mention URL path is :"http://localhost:3005/api/user/status/". This way it's not working. it's showing This request has no response data available
Now I tried with production domain like
URL path is :"http://xxx.xxxx.com/api/user/status/"
This way it's working fine.
Why localhost was not working, I invoke same url directly in my browser working fine. but it's not working in cordova.
Note : I didn't modify anything in www/config.xml file.
What's the problem how can I fix this.
Thanks.
localhost is an alias of 127.0.0.1 even if you are running on an emulator on the same machine, local host is not real. You have to always make calls to an ipaddress or domain name from a device (even virtual devices). This is because on the device localhost is referring to the device not the machine that it may be running from.

PhoneGap app's XMLHttpRequest POST data lost

I'm porting an ajaxed, mobile-optimized website to PhoneGap, but have been unsuccessful in getting any POST to the server. From what I've read, xhreq POSTS are supposed to be possible in PhoneGap.
The specifics: I'm targeting the Android platform using the latest Cordova 3.3.1-0.1.2, the latest Android SDK, and a Galaxy S3 updated by Verizon to Android 4.3. Connectivity is over wifi to my local server. In every attempt, the POST arrives at the server as a GET, with no post data (verified using tcpdump to inspect packets). The mobile-optimized web site works fine in the browser on the same phone, also over wifi.
I've isolated the fail case by creating a brand new Phonegap project, nothing more than:
$ cordova create Hello
$ cd Hello
$ cordova platform add android
Then in index.js, at the end of the onDeviceReady handler, adding a snippet I first tested in a simple browser page (domain substituted here):
// TEST POST CAPABILITY
var req = new XMLHttpRequest();
req.onreadystatechange = function() {
if (req.readyState==4 && (req.status==200 || req.status==0)) {
console.log("POST Response: " + req.responseText);
}
};
var t = new Date().getTime(); // Just to foil any caching
req.open("POST", "http://mydomain.com/services/rpc?t=" + t, true); // async
req.setRequestHeader('Content-type','application/text; charset=utf-8');
var postContent = JSON.stringify({id:t, method:"misc.log", params:[{log:"POST Test"}]});
req.send(postContent);
And then run on the phone with:
$ cordova run android
It fails like the fuller app, arriving at the server as a GET with no post data. I verified a couple of configuration item defaults to make sure they were as required:
In config.xml:
<access origin="*" />
In AndroidManifest.xml:
<uses-permission android:name="android.permission.INTERNET" />
Any ideas as to what might be going wrong, or other things to look in to?
Thanks.
Your content type should be set to
"application/json".
JSON.stringify() creates JSON content.
Next, can you tell us how your server process is determining the request type. Can you post the relevant code?
I would start by adjusting the content type value. See if that makes a difference.
Hope that helps.
The problem was an ip forwarding one, just not the one I'd originally suspected (forwarding to & from port 80 to my local server on port 8080, which I've used for years as a convenience to allow not having to add :8080 into the browser url all the time).
It was this:
In the MX records for "mydomain.com", I had www.mydomain.com pointing to my server's IP address, but the root mydomain.com (the host address I was using in the url to XMLHttpRequest), redirecting to www.mydomain.com.
This worked in a normal browser session, as if you type in mydomain.com, it just goes to www.mydomain.com, then runs from there - and it would use all relative paths in the xhreq's.
In PhoneGap, however, which requires the full path be specified, the POSTs were not making it through the redirect. It was also causing sluggish image loading behavior and some bizarre communication hangups after many loads - I just hadn't realized the problem had the same root cause (rather I was getting worried about WebView performance).
The great news is that POST is working fine now, and the WebView appears to be plenty speedy for my needs.
To summarize the solution: make sure that the subdomain (or lack thereof) in fully qualified urls passed to XMLHttpRequest (as required in PhoneGap) are mapped to an ip address (A record), and not redirected, in the MX records for your domain.

Categories

Resources