OAuth with DropboxAPI without manually copying url to authorize - java

I am trying to create an application (in java) to monitor files in Dropbox (File added, File deleted, File modified... etc). I can get my application to generate a https url using the DropboxAPI. The problem is that I have to manually copy and paste the url into a browser, log in on that browser and hit allow. Once they do this once I can easily store the information so they do not have to redo this process. Unfortunately the program does not stay running up and is frequently restarted.
My hope is that it is possible to get past this step since I will have access to the users Dropbox password and username already in the application.
Any suggestions?

When you say "easily store this information", what information are you storing and where are you storing it?
Once you finish the OAuth flow, save the access token somewhere persistent (like to a file or to a database). That way, if your program gets restarted you just load the access token and use that without re-doing the OAuth flow.
In the official Dropbox Java SDK, load your saved access token and then call setAccessTokenPair.

I have written a simple program to upload files to dropbox server, for backup purpose.
If you are looking for an implementation . You may check out the code via https://github.com/Jintian/dropbox.

Related

I have a existing laravel Web App we wrapped in an android application, and need to save user logins

We have an existing web application we developed and needed to port over to an android application for people in the field. So we have a shell of an android application that just points to the URL and displays it. I want to save the user credentials so if they timeout/close application and re-click the application it will auto log them in always after the first time.
I am looking at SharedPrefrences as other threads here have done, but not sure how to capture the creds from the web input elements. Can I use SharedPrefrences to accomplish this still? If so how do I target that input?
You do NOT save the user credentials. Ever. Saving them means they can be read by malware. And no, encryption can't help as the encryption key would need to be in your app or on your filesystem.
Instead, you have your login API return a token. This token will be sent back to the server with every request (either as a parameter or a cookie). The server will then use this token to look up the user id on the server and figure out who it is. That token can be saved to SharedPreferences. (This is the simplest version, there are more advanced things you can do as well, but this is sufficient).
Why is this safer than storing the password? Because passwords can and frequently are shared between multiple apps, so losing a password can compromise multiple accounts.
BTW, this is also how webapps work. They don't send the username/password with every request, when they login a cookie is saved with a token, and its sent back with every future request.

Allow accessing files on server from a specific mobile app only

I have android app, that makes http request to get files on my server,
I had to migrate all my data to new server, but i still see many get requests on old server, which mean someone stole my links, or my app it self.
I'm currently using NGINX (I can change to Apache) to serve these files,
My question: Is there a way to allow accessing these files from only a single mobile app, based on package name for example ?
Currently, I'm serving files as hot link, example : www.xxx.com/abc.mp4
I read about setting a new user-agent in requests, so that i can allow/deny access based on that value, but if someone tries to reverse engineering my app and re-build it, he can use same user-agent.
So, Please advise if there is an optimal or better solution.
Thanks,
You could disable direct file access and expose some services that send files in their response. By this way you could add some logic to protect your files. I don't know if your app uses some authentication process, you may add some certificate or something else

Open a password protected directory on the server using Java for Android

I'm creating an android app which has a network connection to a server
and I have a PHP file that connects to my database on the server to updates some values and a JSON PHP file.
I need to add these files to a password protected directory on the server for more security but if I do that I can't access them from my app anymore.
Is there a way to access that directory using android java, so only the app
"with the correct password" can access the php files.
I have tried to prevent the access using the "deny from all" in .htaccess file but it will prevent anybody from accessing these files
In short: I want only my app to access my PHP files.
If it is just a simple app for you, you can include a password in the link (GET parameter), but that is not secure at all.
If you actually want it to be secure, you will have to use POST data, and your server must have a SSL certificate so that they communicate without anyone seeing the password.
Also you should deny direct access to the folder containing the above files using a .htaccess file.
You can be find more details and tutorials either in stack overflow or google.

Google Drive API Access my own account

I wish to run a simple process on my server/laptop that will upload files to my google drive on a daily basis, once a day. I don't wish to share this, allow other users to use it etc.
All examples I find seem to involve browsing to an address to gain permission from the user (me) and then getting an auth code etc and proceding
ref: Java quickstart
Is there a way/example to do this without need of a browser, getting permission getting unique auth code each time as I only want to do this for my account?
Can I use a bash script with CURL commands rather than having to use Java?
Yes. See How do I authorise an app (web or installed) without user intervention? (canonical ?)
Yes. It becomes a complicated script if your file is large and you are doing resumable uploads, but for small files it's perfectly feasible. You'll need to play around a bit to get the correct encoding, multipart mime body, mime type and content size, but it's all eminently doable. You'll start by calling Google's auth api with your stored refresh token to get an access token. Then you'll set that access token into an Authorization bearer header as part of your content upload call.

How to secure an SFTP password in an APK file

I'm developing an Android app which has a service to upload images/files to a FTP server.
To make that possible, the app on the device has to log in into the FTP server before sending data.
And here comes my problem. The user does not need to / have to know about the FTP login data. Only the app itself. I have to store the login data in the Java class. But how should I secure the user and password?
I could encrypt it or obfuscate it. But I think it would be possible for a hacker to read the password at the runtime when the "setPassword(passwordString) methods is called by the JVM:
String passwordString = "myPass";
JSch ssh = new JSch();
session = ssh.getSession(SFTP_USER, HOST_ADDRESS, 22);
session.setPassword(passwordString);
So how could I store my credentials inside the APK file and secure them? I don't want anyone to get access to my FTP server.
how could I store my credentials inside the APK file and secure them? I don't want anyone to get access to my FTP server.
The stated problem cannot be solved.
It does not matter how clever your obfuscation technique is. If you hide fixed credentials in the APK file then someone who analyses your app is going to find them.
If you take only one thing from this answer, let it be that having a single, static password for your server is extremely problematic, as you'll never be able to change the password server-side, because you'd break all the apps. It will be a matter of time before your password is public knowledge and there will be nothing you can do about it.
Any reasonable approach requires separate access credentials for every individual user.
A traditional user sign-up system that involves a confirmation email is a pretty good approach. You can use something like Google+ sign-in or Facebook Connect to minimize the hassle for the end user.
If you absolutely insist on having zero user interaction, an approach that might work (somewhat) is to have the app register for Google Cloud Messaging and then send it a push notification containing access credentials, which the app will store in the KeyChain.
If you generate a unique user ID and password for every app installation, you'll be able to monitor the server and block any abusive access credentials without affecting any of the other users. If you somehow factor the code signing identity of the APK file into the process, you'll have a basic defense against people repackaging your app. This approach will not protect you against an intelligent attacker, but it might raise the bar high enough for your purposes.
Also, regardless what you do, be sure to properly verify your server's SSL certificate. If you don't, an attacker will simply run your connection through a proxy server.

Categories