I want to make a web app where the only cost to me is serving the webpage to the user, and all their data is saved to their Google Drive so I don't have to pay for storage or bandwidth.
Is this possible using Google Drive?
I can't see how:
If I want to save something directly from the browser, it needs my application's API key, and I can't put that in the HTML as it is non-secure.
If I try to do anything where the webpage calls my server, the file will have to pass through my server to get to Google.
If I want to save something directly from the browser, it needs my application's API key, and I can't put that in the HTML as it is non-secure.
You need client credentials, api key will only give you access to public data and wont give you the ability to write anything. Web credentials if configured properly are bound to the domain that they are intended to be use for there for they are considered secure.
If I try to do anything where the webpage calls my server, the file will have to pass through my server to get to Google.
Well this is true considering that your server is running the code. There is no way to route directly from the client to the user. Unless you did this with javascript in which case the code is running client sided and running in the users browser.
Related
I have a single page application with some user-related calendars. The task is to write integration with the google calendar. A user should be able to click on 'integrate with google calendar', select his google account, give read+write access to the calendar, and then the application should be able to do a number of things within the user google calendar like creating a new calendar and sync all events inside it with the application data.
I started with this example, https://developers.google.com/calendar/quickstart/js
It works, but as I understand it's for online front end work only. Is it possible to retrieve authentication from this front end and send it to the back end? I want back end to operate server-to-server mode, while the user is offline.
I have checked the other, back end gapi integrations, but they do not look so cool, there're some redirects. I want to keep everything inside a single page with ajax and popups.
In order to access a users data when the user is off line you need something called offline access. When you authecate the user you will need to request offline access then the server will return to you a refresh token.
A refresh token is long lived you will be able to use your refresh token at anytime to request a new access token which will allow you to access the users data.
You cant use offline access with JavaScript you will need to use a server sided language like say node.js, php, phython .... you will not be able to use gapi
I have gone through the Instagram Authentication documentation and I could see that there is no direct way to authenticate other than taking the user to a URL specified by the Instagram.
This is what Instagram documentation says.
In order to receive an access_token, you must do the following:
Direct the user to our authorization url. If the user is not logged
in, they will be asked to log in.
The user will be asked if they would like to grant your application access to her Instagram data.
The server will redirect the user in one of two ways that you choose:
Server-side flow (recommended): Redirect the user to a URI of your
choice. Take the provided code parameter and exchange it for an
access_token by POSTing the code to our access_token url.
Implicit flow: Instead of handling a code, we include the
access_token as a fragment (#) in the URL. This method is less
secure, but allows applications without any server component to
receive an access_token.
See we should take user to a particular URL. Instagram uses OAuth 2.0.
But the thing is that there is a Mac App named Flume, which does not take user to a URL. It simple lets the user enter their username and password, and Flume connects to Instagram API,and the user successfully gets logged in and able to see his media content.
I wonder how Flume doing this? Am I understanding the documentation incorrectly?
Please help. Thanks in advance.
You're reading the documentation correctly.
Flume doesn't use the Instagram API, so it is not affected by its limitations. Instead, it will likely use web scraping by opening the Instagram website in an invisible browser instance, there entering the user data and commands on the behalf of the user, then scraping the results from the next invisible browser page etc.
There are different approaches on how to achieve this in OS X, a starting point could be Web scraping in Objective C. For a conceptual overview, you could have a look at RoboBrowser, which is a Python library but gives you an idea of how this works.
Instead, it will likely use web scraping by opening the Instagram website in an invisible browser instance, there entering the user data and commands on the behalf of the user, then scraping the results from the next invisible browser page etc.
This is actually false. Flume has found a way to use Instagram's internal API to display content. Using a man-in-the middle proxy client such as Charles will show that the network requests that the Flume app makes are very similar to the network requests made by Instagram's different native Apps. Flume mimics Instagram's network requests in order to set HTTP headers/cookies/auth data to retrieve/post information.
I'm happy to post pictures/files to verify this for anyone that may wish for further proof of this.
I have an app that has user generated images, but to access these images, you need to log into the server, otherwise, if you try to access an image URL, you're redirected to the login page.
Is it possible to show these images in chromecast? The documentation only show examples using public URLs.
One approach is to login the user on your sender app and have your server create a (short lived) token or so and pass that back to your sender. Then pass along that token to chromecast and have chromecast use the token. For example, send a URL like "https://some.url.com/my-image.png?token=1234assadasfcrafctvawr32w34v" to your server, from chromecast, and have your server interpret that appropriately.
I am sure you can think of more sophisticated approaches but that is the basic idea.
I have a web service that is being invoked by an ajax call in the JavaScript of my page, but when users view the source, they can see the path to the ASMX file, which they can type into the address bar. I want users to be restricted in viewing and/or accessing the methods of this web service. I want only the JavaScript file to be able to use those methods. Is this possible? These users are not behind any log in.
Thanks in advance!
You can't.
You shouldn't be worried about users knowing your webservices URL, but you should protect what you return with a logged in key or something provided by your website.
The rule is: you don't want people to do something? Check that before on the server side and then return "you are not authorized" or another access error. Even if you try to do a very good job in your JS, it is very easy to monitor what you are accessing with the browser debug features: press F12.
I'm currently working on a rather interesting... project. I have a client who wants to allow form uploads (from a page presented on their server) specifically to their own google drive account. The platform being used is essentially LAMP.
Single (pre-authenticated) google drive account. Multiple otherwise anonymous upload sources (users).
They do not want users to be required to have their own google accounts (rules out simply using Picker on the user's own drive files).
They want some degree of backwards browser compatibility, such as IE8 (rules out XHR to form the post using HTML5's file API to read the filedata). They don't want to use flash/etc due to potential compatibility issues with certain mobile browsers.
What is working:
Authenticating (getting a refresh token, storing, using it to get access tokens as needed)
Uploading a file to the account without metadata
Result of file upload being sent to hidden iframe
Catching the iframe load event via jquery to at least know something has happened
Problems:
The REST API upload endpoint does not support CORS: there is no way to access the result iframe directly. (see: Authorization of Google Drive using JavaScript)
The return from a successful upload is only raw JSON, not JSONP.
There is seemingly no way to host anything with proper headers to open via browser on the googleapis.com domain, so easyXDM and similar multi-iframe with cross origin workaround communication javascript approaches are ruled out.
There is no way to embed a callback URL in the POST from the submit, the API does not allow for it.
The Picker displays errors on trying to upload if you pass it an Oauth2 token that is not for a user who is also authenticated in their browser (assumedly via cookie). Strangely enough you can show files from the Oauth2 token's matching account, but other than in a browser instance where the target Oauth2 token's account matches the already logged in user any file uploads fail with an ambiguous "Server rejected" message. This happens with all files and file types, including files working in an authenticated browser instance. I assume it's an authentication flow/scope issue of some sort. I haven't tried diving the Picker source.
All of the javascript Google Drive API upload examples seem to rely on using HTML 5 to get the file data, so anything of that nature seems to be ruled out.
While files are uploaded, there's no way other than guesstimating which file came from which user, since we can't get the file object ID from the result in our inaccessible iframe. At best we could make a very rough time based guess, but this is a terrible idea in case of concurrency issues.
We can't set the file name or any other identifier for the file (not even a unique folder) because the REST API relies on that metadata being sent via JSON in the post request body, not via form fields. So we end up with file objects in the drive with no names/etc.
We can't create the file with metadata populated server side (or via jquery/XHR, or the google javascript API client) and then update it with a form based upload because the update API endpoint exclusively works with PUT (tested).
We can't upload the files to our local server and then send them to google (proxy them) as the php ini is locked down to prevent larger file uploads (and back to restrictions imposed on using HTML5 or flash for why we can't chunk files/etc).
All of this has been both researched and to varying degrees tried.
At the moment this is going on hold (at least it was a useful way to learn the API and gain a sense of its limitations) and I'm just going to implement something similar on dropbox, but if anyone has any useful input it would be lovely!
e.g. is there any way to get this working with Drive? Have I overlooked something?
I also realize that this is probably essentially a less than intended use-case, so I'm not expecting miracles. I realize that the ideal flow would be to simply allow users to upload if necessary to their own google drives and then have them grant file access to our web app (via Picker or API+our own UI), but this becomes a problem when not all of our own users are necessarily already google account users. I know that google would OBVIOUSLY prefer we get even more people to sign up with them in order to have this happen, but making people sign up for a google account to use our app was ruled out (not out of any prejudice on our part, it was just too many added steps and potential user hurdles). Even simply having them sign in to google if they did have accounts was deemed unwanted for the basic LCD feature functionality, although it's likely to be added as an additional option on top of whatever becomes the base solution.
The biggest problem with the approach you described is you're introducing a big security issue. Allowing an anonymous user to directly upload to Drive from the client requires leaking a shared access token to anyone who comes by. Even with the limited drive.file scope, a malicious or even slightly curious user would be able to list, access (read/update/delete!) any file that was uploaded by that app.
Of course a public drop box feature is still useful, but you really need to proxy those requests to avoid revealing the access token. If your PHP environment is too restrictive, why not run the proxy elsewhere? You can host a simple proxy to handle the uploading just about anywhere -- app engine, heroku, etc. and support whatever features you need to ensure the metadata is set correctly for your app.