I have a google form that I am having pushed out through a Kiosk App and that google form is going to be used for the foreseeable future. Since I am not a Network Engineer or Systems Administrator in my network, the only way of getting the webview element in my App to display the Google form is to hard code it's URL because I have nowhere from which to dynamically update the URL in my App at the moment.
I am also not the Chrome Administrator and because of this I need to send my packaged Kiosk App off site to have it pushed out to my building's Chromebooks which means that for every update that I do, I need to re-package it and have the Chrome guy update it manually.
Since I and many others would prefer to not perform the task noted above on a frequent basis, I am trying to find out how long the Google Form's url will last and/or how often we can expect it to change if it does ever change.
Surely if you have any concerns over the link changing, you can just set up a redirect from a domain you control.
That way even if the kiosk form gets upgraded from Google to something else, you can just change your redirect without recompiling and redistributing your application.
Related
I've made an app in Google Apps Script to use in an iframe on my site. Problem is I have to go through a bunch of steps every time someone new wants to use the app.
My goal:
What I would like to do is automate the app so it just approves anyone who authorizes it when they're initially prompted. Given that the users initial confirmation is the important part, I don't see why it would be a problem to just have the app allow them in, without them having to wait for me to confirm their confirmation.
The Breakdown:
The permissions settings for the app are as follows:
"Execute the app as:" = "User accessing the web app"
"Who has access to the app:" = "Anyone"
The user must obviously have a Google account to use this app, and they have to authorize the app before they can use it. When they do, an email gets sent to me, I have to find it, open it, and click the "Open sharing settings" link which opens the apps script file, then click "send" on the popup just to allow that one person to use the app.
Many people will be requesting authorization, and I don't want to have to check my gmail every day and manually confirm 5 or 10 new authorizations. That's way too much for me, and too much of a pain for the people using it. Despite having put almost a year into coding this thing, I'd rather not deploy it than bother with that. Yea, I definitely should've scoped this out better before coding the bulk of it.
Potential Solution:
This is a relatively naive guess, but would it work for me to make a second app that runs on a schedule, and opens the initial app's script file in an iframe, using sandbox="allow-same-origin allow-popus" attribute, then maybe use javascript to toggle "send" on the "share with others" pop-up?
How can I find a Google App Script web app I deployed and modify it? It does not appear in my drive. Perhaps I didn't save it. Does it persist or disappear eventually? Is there somewhere that list all deployed web apps? If so, I have been unable to find it.
If your webapp is recent, simply replace "exec" at the end of the url with "edit" (without quotes) and you'll get the script editor opened on your script.
(Very old webapp have a different structure but it changed quite a long time ago so I guess you're not concerned with that.)
No. There is nothing like deployed webapps list. if u didn't save, u can't get it back even though you had deployed it. Make a try to open that script with the url available in your browser's history.
At some point in the last couple of days a bug seems to have materialised in my app's Google Drive integration, despite me not having changed anything, and usage remaining fairly constant.
When you left click one of the app's documents in Drive a new about:blank tab opens showing the app's icon and the text "Sorry, an error occurred while opening this file. Please try again. [XXXXX]" where [XXXXX] is a short string that seems to be different every time. The create new works fine, and if you use the right-click menu and open with it also works fine.
All of this makes me think that there is a bug in the latest javascript update to Google Drive's main interface.
In terms of debugging, in the apiconsole the app has...
The initiate oauth2 option unchecked
The allow multiple files option unchecked
Mobile browser support checked
24 mime-types, 61 primary extensions, and 1 secondary extension registered
If it is a bug as Claudio has mentioned, I believe Google Drive SDK documentation needs to be updated too, since 'open' action is described only for "Open With" option:
https://developers.google.com/drive/integrate-open
I'm wondering how to trigger the proper action when registred mime-type can be managed by more than one installed application? Is there a way to set the default open action - or the application which created it will be used as the default? What's happen if you reach the application web by typing the url (not from UI Drive UI create action) and save the content on Drive, since you may be already authorized to do it?
Could a chrome extension be made that maintains a bitcoin wallet while also making it easy for web stores to integrate a one-click purchase experience.
Suppose a button on a webpage is clicked. Is it possible for that to trigger a function call to the chrome extension to send bitcoins?
Obviously letting webpages unlimited access to chrome extensions would never have been designed. But is there some way to make this work securely?
Chrome extensions can insert arbitrary code into web pages (content scripts).
Content scripts are JavaScript files that run in the context of web
pages. By using the standard Document Object Model (DOM), they can
read details of the web pages the browser visits, or make changes to
them.
This code can communicate with the original web page via the DOM and with the rest of the extension via message passing.
In theory, this should suffice. But make it secure, please.
Multibit provides an external application solution
Clicking on a "bitcoin:" protocol URI in Chrome (or any other browser) will transfer the URI over to MultiBit (v0.3+), starting the application if necessary. This approach removes the need for private keys to be held (and potentially shared) within the browser.
This is very dangerous because a single security hole in Chrome could allow any website to empty your wallet.
First, any payment have to be confirmed with the wallet password. But, as that password is typed inside Chrome itself, it might be possible for an attacker to read that password.
In fact, there are so many security issues to solve that I think it's better to let the bitcoin client do that job.
What should be done is a way for any software to ask the bitcoin client for a transaction. The first idea that comes to mind is using DBus.
That way, the Chrome extension would only have to transform any bitcoin address by a button which calls a DBus method.
The blockchain.info Bitcoin Wallet provides some support for this
by using navigator.registerProtocolHandler and Bitcoin URI's. Unfortunately it only works in firefox at present.
I'd like to try my hand at some Chrome Extension Development. The most I have done with extensions is writing some small Greasemonkey scripts in the past.
I would like to use localStorage to store some data and then reveal the data on a extension button click later on. (Its seems like this would be done with a popup page)
How do I run a script everytime a page from lets say http://www.facebook.com/* is loaded?
How do I get access to the page? I think based off my localStorage requirement I would have to go down the background_page route (correct?) Can the background page and popup page communicate across the localStorage?
UPDATE:
I'm actually looking to learn the "Chrome way". I'm not really looking to run an existing Greasemonkey script
Google actually has some pretty good documentation on creating extensions. I recommend thoroughly reading the following two articles if you haven't already done so:
http://code.google.com/chrome/extensions/getstarted.html
http://code.google.com/chrome/extensions/overview.html
If you want to give your extension access when the user browses to Facebook, you'll need to declare that in the extension's manifest.
Unless you're wanting to save data beyond the life of the browser process, you probably don't need to use local storage. In-memory data can just be stored as part of the background page.
Content scripts (which run when you load a page) and background pages (which exist for the duration of the browser process) can communicate via message passing, which is described here:
http://code.google.com/chrome/extensions/messaging.html
Overall, I'd suggest spending some time browsing the Developer's Guide and becoming familiar with the concepts and examples.
Chrome has a feature to automatically convert greasemonkey scripts to extensions!