I built some widgets and uploaded on my local marketplace, is there a way to share that?
And better is it possible to share a Mashup (the widget composition) without giving the
possibility to wiring to the user?
I mean the user should use an application layout without change anything.
You can make public your workspaces/dashboards following the steps documented in the user guide. Only the owner of a workspace will be able to modify it. I think this is what are you searching for.
Another option is to create a packaged mashup using the "Upload to my resources" option in the editor view:
Take a look to the "Advanced" tab, where you can block widgets (make them unremovable), block connections (make wiring connections unremovable) and embed used widgets/operator (by default packaged mashups depends on the user having installed all the required widgets/operators. This way you can distribute the widgets and operators used by the mashup in the same package).
However, take into account that this method is meant for sharing mashup templates, the user will always be able to add additional widgets and create new connections in the wiring view.
Once packaged, mashups/dashboards (and widgets and operators) can be uploaded to a WStore server (e.g. to the Store portal provided on FIWARE Lab) for sharing them with other users. The steps for making this is also described in the WireCloud's user guide.
I have the problem, revisited.
I have set up a working Marketplace instance (v2.3) but am unable to integrate it with Wirecloud. The marketplace is correctly registered but all the requests i am making to this Marketplace are throwing 502 error, even though i am actually able to see some results when querying the Marketplace server through a browser.
Indicatively, i can issue a GET command at http://:8080/FiwareMarketplace/v1/registration/stores/ and get an answer, but Wirecloud's internal APIs return a 502 (Bad Gateway).
Any idea on what might have gone wrong?
PS: This happens for WC v0.6.5. When upgrading to a newer (Beta) version of WC, everything seems to be performing as expected, i.e. the marketplace is correctly inserted and the stores are correctly retrieved and processed.
Related
I'm building a Chrome kiosk app that will be in a public space. Users can interact with the app, but there are a variety of settings (server addresses, timeouts, etc.) that need to be set. I'm looking for a strategy on how to allow access to that administration config.
On first run - This is straightforward, but I want administrators to be able to pull it up again.
Detect if the app ran as a kiosk app or manually - This would kind of work, not sure if it's the greatest
Detect some key combination - Ctrl + Alt + Something switches over to the settings page, this feels like people could stumble on it accidentally.
Is there another approach I'm missing?
If your Chrome device(s) is managed you have a further option which is to use the Chrome App Management area within the Google Apps admin interface.
To do this you code your app to use the storage.managed API and this should allow a Configure section for your app within Chrome App Management.
I haven't tried this myself yet but this appears to be the way the Chrome Sign Builder app is configured with its schedule.
Another approach would be to have an administrator login button in a corner of the app. You can set a default password for administrators, which could then be changed in the settings dialog.
You can also think of combining suggestions you have made, first run and then a key combination, and this could bring up a password prompt as also suggested. For an example of this see the Zebradog Kiosk app which is in GitHub so you can see code of how this could be done.
I use ctrl-alt-S at boot. This allows me to login and make changes. I know you have to do a couple of reboots, but it is out of service during admin time anyway.
I have a fairly basic question regarding the new Box API v2.
I have developed a Firefox extension (FEBE) that performs automatic, scheduled, unattended backups of the user's Firefox profile. These backups can (optionally) be automatically uploaded to the user's Box account. I currently use the v1 API and it has been working fine for several years. I now see the v1 API is being deprecated in December, 2013. Does this mean it will no longer work, or that it is just no longer supported?
If I have to re-write my code (JavaScript) to handle the v2 API, will I still be able to provide the upload capability without any user intervention? FEBE securely stores the user's Box username and password and silently logs in to initiate the upload. From what I've been able to research so far, it seems the OAuth 2 verification process requires an interstitial page to confirm the users credentials. Is this true? If so, that would remove the 'unattended' aspect of the backup.
Also, can anyone recommend a good source of JavaScript code snippets that show examples of the Box v2 API in action (preferably not JQuery, just plain, old-fashion JavaScript)?
Does this mean it will no longer work, or that it is just no longer supported?
Yes, in December 2013 the V1 API will cease to function in its entirety.
…will I still be able to provide the upload capability without any user intervention?
The user will need to go through an initial web flow once to authorize your use of their account. After that, you can perform everything in the background.
There aren't any good sources of sample JS that I'm aware of, hopefully someone else can chime in on that.
I read the OAuth documentation on Box's website, and understood the steps to give resource access to application.
However, it looks like all resources (all folders and files) under box account will be exposed to authorized application. Is it possible to only give certain folders' access to application instead of all of them?
thank you very much.
We're in the process of building out additional scopes but currently the only one available is full account read/write.
I reviewed the Box authentication documentation as well as the other StackOverflow questions but I'm still unable to find definite answer.
My client is an enterprise Box client and would like to build a company's internal web application that would login into Box.com using service/admin account and create folder and upload a file. The uploaded folder will be available to specific customer that will login into Box and upload additional files.
I created a sequence diagram to depict the same.
Would you let me know if this is a supported Box authentication model? Can the Box 2.0 Beta API Token be used to login as service account and create file/folder/share?
Thanks for your help!
There are several options that could work for you. Let me suggest the simplest one first, and if that is not sufficient, then I can suggest other ways to accomplish your goal.
You can use the regular Box authentication for your solution. To do so, simply get an API key and an auth-token for your application. Then, after you have uploaded your file, use the V2 API to create a shared link for your file. You can email that shared link to the client, and they can use the link to access the file.
there has been new developments since this question was posted, and now it's possible to use JWT (JSON Web Token) and Box Developers Edition to access Box.
If you create a developer account you will be able to create App users and login using an enterprise id and a private key file. Check out the docs for more information: Box Developer Edition
Additonally, boxsdk comes with support for Box Developer Edition
I'm working on a Google Drive interface for Emacs. The concept is that Emacs could provide a platform-agnostic way to load, modify and save text documents stored in Google Drive. I've registered my app and can authenticate with OAuth2 and get a file listing with the Docs List API, but when I try to execute an Insert with the Google Drive API, I see an error:
"The authenticated user has not installed the app with client id ..."
Reading further, it seems I need to publish my Emacs application in the Chrome Web Store to get access to the Drive API. That doesn't make sense to me...I noticed that there is a FUSE project in development for Google Drive, which suggests that native development is possible. When I skimmed the code, however, I didn't see a Chrome Web Store component to getting it working.
Am I trying to misuse the API, or is there an route to make this work that makes more sense?
EDIT:
According to Ali Afshar, of the Google Drive team, installation is no longer required to use this API. So what follows may no longer be relevant, but will be left for historical purposes.
So, first off the API does not support application development in the sense that we are both doing it, I wouldn't use the word native though. The good news is I have been doing some research and Google Drive is really just a rebranding of Google Docs. So the Google Docs API could be a good choice as well for the same purposes.
Anyway, here's the steps to solve the error: "The authenticated user has not installed the app with client id ..." Which is a 403 error, for the sake of this answer. These steps assume you have set up an app in the chrome web store as is required, and installed it. I am working on my local machine too, with my project: http://github.com/tom-dignan/gdrive-cli which I have gotten past this error, so I think you should keep plugging away at your emacs version, because I think we can make this work.
a. Open the Google APIs console.
b. Confirm you've already enabled the apis under "API Access" both the API and SDK for Google drive should be enabled. There you get your client secrets/api keys and such. I am almost positive you've done this already, so go ahead to C. (this is here for others who may have missed it)
c. In the left navigation bar, under "Drive SDK" you will need to do the following:
Add a "Support URL" (required)
Add at least a small 16x16 application icon (required)
Add "OAuth Client ID (Required)" under Drive Integration (I was just tinkering and this seems to be the key field.)
Add "Open URL (Required) URL to open for your app from the google drive UI."
Check off "Multiple File Support"
Add some MIME types and file extensions, "text/plain", and txt for example
Add the the auth scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
Don't bother trying to add the auth scopes for Google Docs here, because it won't work. Google does not want us to use it that way because files that drive apps create should be private to that app. Integration with Google Docs will have to be separate.
Now I know you must be thinking "why do I have to add some of these..." It's because the form makes them required fields. In mine, I put a couple URLs that point to static HTML pages.
Once you've done the above, clean up your state and reinstall your chrome app. Then try your code again, and it should stop giving you a 403.