We have received a new Pepper robot about 4 weeks ago. The robot uses the Python SDK to NAOqi 2.5.10.7. We are able to work with the Python API functions, program our dialogues and new behaviors, but we cannot access most of the applications in the Aldebaran Cloud. At https://cloud.aldebaran-robotics.com/application/ there are (after Sign in) only 16 applications listed, most of which are either already contained in the Basic channel or they are incompatible with Pepper (Grasping, Move Recorder, ...) even with the filter Pepper selected at the top.
(source: hales at charon.fi.muni.cz)
Moreover, a number of these (and others, mentioned elsewhere in the documentation or on the web) are not accessible - when going to their URL, the page redirects to the main cloud page :-( E.g.
https://cloud.aldebaran-robotics.com/application/come-here/
https://cloud.aldebaran-robotics.com/application/explore-c8782b/
https://cloud.aldebaran-robotics.com/application/exploration-manager/
These even include the applications already installed on the robot - there are 47 packages currently installed (seen in the Manage robot page), so most of them are not accessible at the web. Some of the installed applications were added by Aldebaran support, who evidently can access them (e.g. https://cloud.aldebaran-robotics.com/application/autonomous-recharge/), but we cannot.
We have already asked the support about this (several times), but they did not come with any solution.
Is this caused by some error with our account settings?
Related
I can test my addin in Excel for Windows / Online, but can't test it from a Mac and iPad because I don't have that setup and don't have plans to acquire it.
I'm being rejected because of Mac tests by the team, and I'm unable to fix the errors.
Is there any way to cap Macs from the manifest file and don't make them avaible to Mac users when they browse the store?
Office Web Add-ins are designed to work across the entire Office platform. As such, there isn't a mechanism for enabling the add-in by platform.
In the end, these add-ins are just web apps that run within a browser context. If you're running into a blocker on a single platform, posting those questions on Stack Overflow would be a reasonable next-step. Generally browser specific issues are well known by the community here and can be quickly answered.
There are also several vendors that offer cloud-based Mac access. MacinCloud for example has a $1 per hour option (you pre-pay for 30 hours so it's a $30 investment). I've used this service myself for testing add-ins.
What versions of chrome are compatible with loadrunner 11.52 on windows?
I saw a post that said version 26 was supported, but Im looking to record using chrome version 13 on windows 7
NB: Browser version is mandated by the project.
NNB: Assume playback is browser agnostic - as the commands generated will send the raw HTTP(S) requests to the target server, without any UI
All versions when using the proxy recording model.
I just recorded again , and quit before I got the site up (so recorded for about 4 minutes with an empty chrome screen and a spinning timer) to see what Loadrunner recorded - I got web_url, web_add_cookie & web_custom_request for google safebrowsing & related api - ...
Unless you work for Google or have their expressed written permission then you do not use automated tools against their site. This is why the sample applications exist. Or, you may download and install onto a server you own, control, manage, ... any of the thousands of open source applications which are available on the market.
Pointing an automated tool at a site you don't own, manage or control is no different than driving down the street and shooting at parked cars, homes and signs just because they are there and you can. Pointing a performance testing tool at the same is akin to pointing a piece of field artillery at someone's home. This is something you do not engage in as a performance test professional.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 13 days ago.
The community reviewed whether to reopen this question 13 days ago and left it closed:
Original close reason(s) were not resolved
Improve this question
What are the existing client-side architectures to access a local Smart Card thru a PC/SC Smart Card reader (ISO 7816-3, ISO 14443) from a generic browser (connected to a server through http(s)), preferably from Javascript, with the minimum installation hassle for the end user? The server needs to be able to at least issue APDUs of its choice to the card (or perhaps delegate some of that to client-side code that it generates). I am assuming availability on the client side of a working PC/SC stack, complete with Smart Card reader. That's a reasonable assumption at least on Windows since XP, modern OS X and Unixes.
I have so far identified the following options:
Some custom ActiveX. That's what my existing application uses (we developed it in-house), deployment is quite easy for clients with IE once they get the clearance to install the ActiveX, but it does not match the "generic browser" requirement.
Update: ActiveX is supported mostly by the deprecated IE, including IE11; but not by Edge.
Some PC/SC browser extension using the Netscape Plugin API, which seems like a smooth extension of the above. The only ready-made one I located is SConnect (webarchive). It's no longer promoted (Update: thought still actively maintained and used late 2020 in at least one application), it's API documentation (webarchive) is no longer officially available, and it has strong ties to a particular Smart Card and reader vendor. The principle may be nice, but making such a plugin for every platform would be a lot of work.
Update: NPAPI support is dropped by many browsers, including Chrome and Firefox.
A Java Applet, running on top of Oracle's JVM (1.)6 or better, which comes with javax.smartcardio. That's fine from a functional point of view, well documented, I can live with the few known bugs, but I'm afraid of an irresistible downwards spiral regarding acceptance of Java-as-a-browser-extension.
[update, Feb 2021]: This answer considered the WebUSB API as a promising solution solution in 2015, then reported in 2019 that can't work or is abandoned. I made a question about it there.
Any other idea?
Also: is there some way to prevent abuse of whatever PC/SC interface the browser has by a rogue server (e.g. presenting 3 wrong PINs to block a card, just for the nastiness of it; or making some even more evil things).
The fact is that browsers can't talk to (cryptographic) smart cards for other purposes than establishing SSL.
You shall need additional code, executed by the browser, to access smart cards.
There are tens of custom and proprietary plugins (using all three options you mentioned) for various purposes (signing being the most popular, I guess) built because there is no standard or universally accepted way, at least in Europe and I 'm sure elsewhere as well.
Creating, distributing and maintaining your own shall be a blast, because browsers release every month or so and every new release changes sanboxing ir UI tricks, so you may need to adjust your code quite often.
And you probably would want to have GUI capabilities, at least for asking the permission of the user to access a card or some functionality on it.
For creating a multiple-platform, multiple browser plugin, something like firebreath could be used.
Personally, I don't believe that exposing PC/SC to the web is any good. PC/SC is by nature qute a low level protocol that when exposing this, you could as well expose block level access to your disk and hope that "applications on the web are mine only and they behave well" (this should answer your "Also"). At the same time a thin shim like SConnect is the easiest to create, for providing a javscript plugin.sendAPDU()-style code (or just wrap all the PC/SC API and let the javascript caller take care of the same level of details as in native PC/SC API use case).
Creating a plugin for this purpose is usually driven by acute current deficiencies.
Addressing the future (mobile etc) is another story, where things like W3C webcrypto and OpenMobile API will probably finally somehow create something that exposes client-side key containers to web applications. If your target with smart cards is cryptography, my suggestion is to avoid PC/SC and use platform services (CryptoAPI on Windows, Keychain on OSX, PKCS#11 on Linux)
Any kind of design has requirements. This all applies if you're thinking of using keys rather than arbitrary APDU-s. If your requirement is to send arbitrary APDU-s, do create a plugin and just go with it.
Update (8/2016): A new API for the Web called WebUSB API is being discussed. You can already use it with Chrome v54+.
This standard will be implemented in all major browsers and will replace the need for third-party applications or extensions for Smard Cards :-)
So the new answer is YES!
And the OSI-like architecture stack is:
PC/SC
CCID v1.1
WebUSB API
USB driver, i.e. libusb.
2019 Update: As #vlp commented, it seems that it doesn't work any in Chrome because they decided to block WebUSB for smartcards for some specious reasons :-(
Note: Google annonced that they will abandon Chrome Apps in 2017.
Previous anwser:
Now (2015) you can create a Google Chrome App, using the chrome.usb API.
Then you access the smartcard reader via its CCID-compliant interface.
It's not cross-browser but JavaScript programmable & cross-platform.
Anyway Netscape Plugin API (NPAPI) is not supported any more by modern browsers. And Java applets are being dismissed by browser vendors.
I have just released a beta plugin addressing this problem.
This beta code is available here:
https://github.com/ubinity/webpcsc-firebreath
This plugin is based on the firebreath framework and has been beta-tested with Fireofx and Chrome under Linux/WinXP/Win7. Source code and extension pack are provided.
The basic idea is to provide a PCSLite API access and then develop a more friendly JS-api on top of this.
This plugin is under active development, so feel free to send any report and request.
For your first question I have little hope: either you are satisied with a very small subset of smart card functionality (like signing e-Mail or PDFs), then you may use some ready-made software (like PKCS), ideally maintained by the smart card company, or you want broader functionality and need to invest considerable effort on your own. Surely PCSC is the starting point to choose.
At least for your "also:" there is some hope.
1) Note, that some specifications (e.g. ICAO/German BSI TR-3110) request a method, where a PIN is not blocked, but uses a substantial amount of time as soon as the error counter hits 1 before replying. The final attempt must be enabled using a different command, otherwise no further comparison and error counter adjustment is done.
2) Simply protect the Verify command by requiring secure messaging. Sensitive applications use secure messaging for everything, so first step a session key is negtiated, which is second applied to all succeeding commands and responses. The effect would be, that the command is rejected due to incorrect MACs long before a comparison or modification of error counter is done.
There is another browser plugin similar to the one proposed by #cslashm available at http://github.com/cardid/WebCard. Is also open source and can be installed with "minimum installation hassle" as required in the original question. You can see an example of use visiting http://plugin.cardid.org
WebCard has been tested in IE 8 through 11, Chrome and Firefox in Windows and in Chrome and Safari in Mac OS X. Since is just a wrapper for PC/SC it requires in Mac OS X the installation of SmartCard Services from http://smartcardservices.macosforge.com
As chrome and firefox going to stop the support of NPAPI Plugin, there is no secure solution available to maintain the session for the smart card reading instead your certificate of the card have support for mutual ssl ,I answered for the similar question source,It might help
Its dirty, but if its acceptable / viable to install a bridge daemon/service on the client machine, then you can write a local bridge service (e.g. in python / pyscard) that exposes the smartcard via a REST interface, then have javascript in the browser that mediates between that local service (facade) and the remote server API.
Web Serial API (draft) can be used to communicate with a serial smart card reader from some browsers.
Buyer beware: This API is a draft and may be changed/abandoned at any time.
Speaking about Chrome, you can now use the Smart Card Connector app provided by Google which bundles the PC/SC-Lite port and the generic CCID driver.
The app itself works through the chrome.usb API, that was mentioned by the previous commenters.
So, instead of rewriting the whole stack (starting from the lowest level - raw USB), it's now possible for developers to code only the part that works on top of PC/SC API - which is exposed by the Connector app.
Clients,clients,clients...plugins,..JSApis..
Well..
For certain we know this : All browsers, when communicating to an Apache or IIS servers, are actually signing "something" when a https/SSL handshake process is needed.
For instance, a typical Apache configuration like this:
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +FakeBasicAuth +StdEnvVars +ExportCertData +OptRenegotiate
Initiates a PIN pad pop up and the user must insert the smartcard pin to go on.
Well, my idea is : why not make the turn to the server, and tweak that behaviour, in order to upload a bytestream of stuff to sign something when a handshake is initiaded?
I have a setup where a smartcard reader is scanned to login a user. The PC/SC library work great on desktop. Somebody had mentioned to use
Emscripten (https://github.com/kripken/emscripten) compiler which compiles c++ into JavaScript code. But that didn't work well because some of the functions being used by PC/SC are only available server side.
After much research. I finally gave up on a client side solution, chrome web usb API also couldn't recognize the reader.
I then decided to give signalR a try and set up a hub on the PC connected to the smartcard reader and this approach worked out very well.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
Google has open-sourced the auto update mechanism used in Google Chrome as Omaha.
It seems quite complicated and difficult to configure for anybody who isn't Google. What is the experience using Omaha in projects? Can it be recommended?
We use Omaha for our products. Initially there was quite a bit of work to change hardcoded URLs and strings. We also had to implement the server ourselves, because there was not yet an open source implementation. Today, I would use omaha-server.
There are no regrets with ditching our old client update solution and going with Omaha.
Perhaps, you can leverage the courgette algorithm, which is the update mechanism that is used in Google Chrome. It is really easy to use and apply to your infrastructure. Currently, it just works for Windows operating systems. Windows users of Chrome receive updates in small chunks, unlike Mac and Linux users who still receive the chunks in total size.
You can find the source code here in the Chromium SVN repository. It is a compression algorithm to apply small updates to Google Chrome instead of sending the whole distribution all the time. Rather than push the whole 10 MB to the user, you can push just the diff of the changes.
More information on how Courgette works can be found here and the official blog post about it here.
It works like this:
server:
hint = make_hint(original, update)
guess = make_guess(original, hint)
diff = bsdiff(concat(original, guess), update)
transmit hint, diff
client
receive hint, diff
guess = make_guess(original, hint)
update = bspatch(concat(original, guess), diff)
When you check out the source, you can compile it as an executable (right click compile in Visual Studio) and you can use the application in that form for testing:
Usage:
courgette -dis <executable_file> <binary_assembly_file>
courgette -asm <binary_assembly_file> <executable_file>
courgette -disadj <executable_file> <reference> <binary_assembly_file>
courgette -gen <v1> <v2> <patch>
courgette -apply <v1> <patch> <v2>
Or, you can include that within your application and do the updates from there. You can imitate the Omaha auto update environment by creating your own service that you periodically check and run Courgette.
I've been using Omaha in various projects since 2016. The projects had between a handful and millions of update clients. Target operating systems were mostly Windows, but also some Linux devices and (via Sparkle) macOS.
Omaha is difficult to set up because it requires you to edit Google's C++ implementation. You also need a corresponding server. The standard implementation is omaha-server and does not come from Google. However, in return it also supports Sparkle for automatic updates on Mac (hence why I mentioned Sparkle above).
While setting up the above components is difficult, once they are configured they are work extremely well. This is perhaps not surprising given that Google use Omaha to update millions (billions?) of devices.
To help others get started with Omaha, I wrote a tutorial that gives a quick overview of how it works.
UPDATE
Customizing google omaha isn't that easy espacialy if you have no knowledge about c++, python or com.
Updates aren't published that frequently
crystalnix/omaha is managed by the community and they try to merge the main repo into their's; additional features are implemented and basic things are fixed
google/omaha is more active and changes from google are added but not frequently
To implement manual updates in any language you can use the com classes
Resume
google omaha is still alive but in a lazy way
bugs are fixed but do not expect hotfixes
google omaha fits for windows client apps supported from windows vista and upwards
the server side I'm using supports also sparkle for crossplatform support
feedbacks and crashes are also supported on the server
feedbacks are sent with the google protocol buffers
crash handling is done with breakpad
I personaly would go for google omaha instead of implementing my own solution. However we will discuss this internal.
In the .NET world you might want to take a look at ClickOnce deployment.
An auto-update mechanism is something I'd personally code myself, and always have in the past. Unless you have a multi-gigabyte application and want to upload bits and pieces only, just rely on your own code/installer. That said, I've not looked at Google's open source library at all.. and didn't even know it existed. I can't imagine it offering anything superior to what you could code yourself, and with your own code you aren't bound by any licensing restrictions.