I have been playing with this for days and no luck. One of the challenges is not being able to watch the network traffic of "UrlFetch" since it is on Googles wires.
Anyone interested in posting a detailed example of using "Digest Auth" and Google Apps Script?
It should be possible, but I'm not sure I've seen it done before. I looked into it briefly once but digest authentication is pretty complicated and it's a task to code it by hand. If you are looking for a server to test against I'd recommend test.webdav.org, and there are some existing JavaScript libraries like dijestj that you may be able to leverage or learn from.
Related
I have multiple spreadsheet bound projects, and I want once in a while run all of them together. Is there a possibility to automate this, as I do not want open each project and run it manually. And as I understand I cannot create installable timed triggers, as I have more than 20, and I am not collaborating with anyone.
My vision - is to create a standalone project where I loop through all the projects using their project/script key(id)s. I only do not know if this is possible, and if yes how do I code this - a call of a script knowing its scriptid?
In order to provide a proper response to the question, I'm writing this answer as a community wiki, since the issue was resolved from the comments section.
Yes, it's possible to run several projects at once with Apps Script with method scripts.run
You can use this example to have an idea on how to do it with Apps Script.
The documentation that #Ruben shared above has specific details to accomplish what you're looking for. Make sure to check the requirements and also the limitations to check if the projects you're trying to run meet the requirements.
I've been thinking about a project I'd like to start using the Google Drive API. My idea was to make a webpage (using Laravel) to let guests download files. I'd have 3 different types of users: the guests, that would be able to download files, the logged in users, that would be able to upload files, and the admins, which would be able to do all of that plus delete files (these files would be PDFs only).
Also, the server it would run on wouldn't have a lot of hard drive space for storing the files, it would just host the page and maybe keep some of the most important files. But the thing is, I have no experience whatsoever with this API. And I would hate to go through all of this trouble just to discover that it can't be done. I've tried reading the documentation but I still don't know if this is doable, and I can't find reliable tutorials (also, I don't know what is reliable, I've never worked with it).
So, for anyone who has already done something with the API, is this doable? Will the download speeds be too slow? Will users without accounts be able to download? Also, do you know any tutorials that are reliable and do it the right way? Or is the documentation the only thing I'll find/need?
Thanks in advance.
Yes,
All three cases can be handled with google drive sdk. You need to explore API in depth. Creation and downloads are easy and upload is tricky.
I recently used google drive api in a chrome extension that uploads images directly to drive here
You can ask questions regarding api usages here.
To start with, I would suggest going through one of the given Quickstarts in Google Drive REST API Overview.
Secondly, please note of the Requirements and Best Practices that a Drive API integration must adopt.
As mentioned:
Requirements
Following an "open with" action, applications must check that the user is authorized to read/write the document to which the passed document ID refers.
Best practices
In the "create new" flow, Google Drive provides your application with an authorization code. This code should be upgraded to an access token as soon as possible before applications take other actions.
Lastly, this SO post - Good tutorial on Google Drive SDK and OAuth might also help.
I received this email and due to my lack of experience in google drive, I am unsure of how to go about troubleshooting this.
Google
IMPORTANT: Steps to migrate from discontinued Documents List API
Hello administrators,
We recently posted a reminder that Documents List API will be discontinued on April 20, 2015. This change means that service calls for this API will no longer be supported, and any Google Apps features that are implemented using this API will no longer function.
Our records indicate that you may have an application that uses Documents List API, and we recommend that you migrate to Drive API, which has comparable functionality, as soon as possible.
Here's what you need to do:
Determine if you have an application that makes requests to these types of URLs:
(took out urls since this format did not allow me to send more than two)
Migrate the applications to Drive API.
If you have questions about migration, please contact Google Apps for Work Support.
Sincerely,
The Google Apps for Work Team
How do I determine, which, if any, docs are going to cease to function post 4/20? Is there a way to organize my current list of docs (I have many) to see how many I need to pay attention to? In terms of migrating, is there a migrating tool available online?
From what I have read, I feel like this doesn't even pertain to my current drive. My understanding is that this is for developers not casual users such as myself. Am I wrong in that assumption?
Thank you for all your help in this matter. If I am not explaining everything to the level you need, please let me know. I am just confused by the email and want to make sure I stay ahead of this.
Best,
Nathan
The key part of the email is Our records indicate that you may have an application that uses Documents List API
If you have such an app (you should know since by implication, you wrote it), then you have a lot of work to do over the next two weeks. If you don't, then relax. Your documents are not affected by this announcement, only the app that Google thinks you once wrote.
It's possible it's referring to an app you have installed, in which case there is nothing you can do other than hope the developer has a new version.
In my case Google Apps Sync for Microsoft Outlook and Google Drive Windows seem to be the 2 applications that are requesting access to these depecrated scopes ... Come on Google, spread the word internally !
The situation:
I'm currently creating an advanced Google Apps application which I would like to release later on in the Google Add-On store (It's an Add-On for Google Spreadsheets).
My application has since the beginning been developed using the UiInstance service for creating the User Interface. It works swell and I'm really happy with the results.
However, if I consult the Add-On style guide this is mentioned:
Use the add-ons CSS package in your HTML service pages. (And don't use UI service to create a public add-on — it won't look as professional.)
Also, the UI service is marked as Experimental in the Google Apps Reference Guide, this might also be a problem for publicly releasing it (can anybody point me in the right direction to ask more information on this?)
The question; Does anybody know about the plans for the UI Service? Might this get deprecated in the (near) future? I've been looking for more information on this but I did not find it. Please keep in mind that your guess is as good as mine.
Should I start recreating my UI with the HTML Service or is there any future for the UI Service?
My personal opinion; I think the UI Service makes it a lot easier to create a User Interface, still having the possibility to adjust it as you wish.
You are perfectly right when you say "your guess is as good as mine" but I see at least 2 arguments that makes me think HTML Service is the way to go :
the "recommendation" about not using UiApp in add-on is not really a recommendation, it's definitely a requirement. They won't approve an add-on build with UiApp (and approval is also a mandatory step)
They provide a link to a Google static CSS sheet that will determine the "look and feel" of the add-ons for buttons, fonts and about all graphic elements used in the Ui so that, if ever they feel like changing something in the Ui, they have full control on it and don't rely on each app developer good will to update it. This would not be the case in UiApp of course.
And lastly, they stopped maintaining UiApp and deprecated all methods that were having issues, leaving it "as it is" so I guess the future is - at the least - uncertain...
I fully agree with you that when you know how to use UiApp it is fairly easy but I know also that this is more a personal point of view that not so much people share. If you are a "normal" web developer then HTML and JQuery are certainly more familiar and far more easy to use.
I guess (I know it's just a personal guess ;-) it's time to start your "mutation" to HTML Service, at least if your goal is to publish your apps.
Please, help me to choose which one to use for my university project (I want to develop a shared multiuser whiteboard).
In particular, I am interested in the performance of message exchange between users and server using Channel API and Socket.io: which one is quicker and why?
I have implemented an initial version of the whiteboard http://jvyrushelloworld.appspot.com/ by following this tutorial: http://blog.greweb.fr/2012/03/30-minutes-to-make-a-multi-user-real-time-paint-with-play-2-framework-canvas-and-websocket/ The code I used is pretty much the same, except for the side and message exchange method: I used python, Google Channel API for message exchange; the guy who wrote the tutorial used Play 2 framework and Web sockets.
As you see, the web socket tutorial version works much faster (don't know if it is my mistake or google api channel performance issue). Of course, a lot of optimization can be done to improve the performance, but I wonder if it is worth to go on using Channel API for that project or is it better to switch to socket.io?