I'm trying to understand function of the landing page. According to specification:
The iLandingPage field, when non-zero, indicates a landing page which the device manufacturer would like the user to visit in order to control their device. The UA MAY suggest the user navigate to this URL when the device is connected.
As far as I do understand the main purpose of landing page to provide
notification to the user which page is recommended to be used with WebUSB complaint device. So I have a couple of questions:
is landing page also preventing user from accessing the other websites? Is Chrome (Chromium) blocking access to the sites that are not matching landing page?
is landing page mandatory? Can we avoid using at all by simply setting iLandingPage to 0?
if URL for landing page is mandatory - what would be preferred way of making it configurable (i.e. like after uploading firmware to the device)?
I saw in one of the thread information about blacklist for WebUSB devices . How can I access WebUSB blacklist in Chrome/Chromium?
is landing page also preventing user from accessing the other websites? Is Chrome (Chromium) blocking access to the sites that are not matching landing page?
No, the landing page is not used to limit which websites can access the device. In an earlier version of the WebUSB API draft, there were custom descriptors that defined filters for which domains could access which interfaces. Those descriptors are no longer used, so any site served over HTTPS can request access to your device.
The landing page is only used to prompt the user that there is a companion web page for the USB device that was just detected. The user is not obliged to click on it and on some platforms (Windows, Android), the notification is not shown at all due to technical limitations.
is landing page mandatory? Can we avoid using at all by simply setting iLandingPage to 0?
It is not mandatory - you can simply set it to zero. In fact, if you do not want a landing page, you do not even need to supply the WebUSB Platform Capability Descriptor. Chrome will still allow you to manually select your device from the device picker even without the descriptor.
if URL for landing page is mandatory - what would be preferred way of making it configurable (i.e. like after uploading firmware to the device)?
As above, it is not mandatory, but since the GET_URL request is separate from the request for the platform capability descriptor, you can easily generate the descriptor in RAM and fill in whatever URL you wish at runtime.
I saw in one of the thread information about blacklist for WebUSB devices . How can I access WebUSB blacklist in Chrome/Chromium?
There are two different blacklists for Chrome:
The WebUSB Interface Class Filter restricts access to certain classes of USB interfaces: Audio, Video, HID, Mass Storage, Smart Card, Wireless Controller (Bluetooth and Wireless USB).
The USB blocklist restricts access to USB devices based on their vendor ID / product ID pair. This mostly applies to U2F devices.
Related
Issue: appears to be that banno framework is "remembering" the urls. This is happening in a mobile browser when the user does not close the tab or browser. When the user opens the page, banno is remembering the url from last time and trying to load the same url.
What needs to happen is that banno needs to fully reload the page so that we can go retrieve a new url and log the user in again.
Could it be how they treat plugins when a browser is left open. A url that is loaded is not good forever.
Odds are good that the situation you're encountering is described in https://stackoverflow.com/a/71267143/6680761
Essential info from that link is:
Part of keeping state of the page is keeping authentication data. The OAuth flow used to initially authenticate the user is not intended to be used on every page refresh. It's expected that the embedded web application will keep its own authentication state. How this is done is usually very specific to the language and platform used for the embedded web application. However all strategies almost exclusively use a cookie which is destroyed when the application closes.
The Oauth callback URL with an authentication code should be redirected away from once the code is exchanged for an access token. From that point forward your app should be using its own authentication mechanism.
I am new to computer networks and have a simple question. Assuming that we want to visit a website www.aaa.com, and the website includes a picture . When we try to access aaa.com, who launched the resource request on bbb.com, the aaa.com server or the user-side browser? I have two thoughts:
User first downloaded the html file of aaa.com and the browser executed the code in it, so the user browser finishes resource request.
The aaa.com launches the request, and prepares all the sources, then gives back to user browser.
Which idea is right?
Unless a visitor is using a proxy which redirects all traffic through website aaa.com then what bbb.com site will see is a request made from the users browser.
Your HTML file essentially acts as a pointer to all the resources needed by the website; browser then fetches all the resources accordingly. This is usually called a Cross-Origin call.
You can open up your Developer Tools in your browser to see the calls under the Network tab.
If you want to delve deeper into the subject take a look at CORS on MDN.
Issue:
A Dashboard (created in SAP Dashboards) has URL Buttons set up with OpenDocument URLs as links.
When this ‘landing page dashboard’ is opened from the BI Launchpad (whether it’s saved as your default/home page or accessed directly from the platform file structure)… it requires additional authentication to follow an OpenDocument URL. Regardless of file type, Webi documents, or other dashboard files.
Not all users experience this issue, but at least ½ do. Need to understand the difference in behavior and the root cause of it to advise fix.
Referencing OpenDocument user session documentation, there are workarounds with tokens and serialized sessions, but what other settings come into play to explain that only half of the users are impacted and prompted when using native functionality from launchpad?
One possible reason for this behavior is that the domain of the BO server as displayed in the address bar of the browser is different from the domain in the openDocument link.
For example, after logging in to BI launch pad, the browser displays the following in the address bar:
http://bi4server.company.com/BOE/BI
but the openDocument link is:
http://bi4server/BOE/OpenDocument/opendoc.....
In this case, the domain is different so the original session isn't recognized. If this is the case, the easiest solution is to remove the protocol and domain values from the URL, so that it begins with:
/BOE/OpenDocument/opendoc.....
I've developed an iPad web app that uses the appcache. It's not intended to be a fully offline app but I use the appcache to store large image files so that they're not sent over 3G. Problem is when the manifest is updated the appcache updates whether the iPad is on wifi or 3G, which could be expensive.
Is it possible to have the user decide if the appcache can be updated or not? From what I've seen, this isn't possible, it all happens automatically, you just get events. But perhaps there's some trickery like writing the manifest on the fly or similar.
Using PHP on the server side if that helps. Thanks.
Connection Type: Theory & Future
There is a draft spec of Network Information API on W3C that provides the information of the connection type (ethernet wifi 2g 3g 4g etc.), but it hasn't been implemented on any browser yet apart from:
the stock Android browser on Android 2.2+ (not the Google Chrome browser)
navigator.connection.type // Based on W3C draft, (Implemented on stock Android browser)
and PhoneGap which is not exactly a browser
navigator.network.connection.type // on PhoneGap
Having that information in the future you could detect if the user has cellular data, then temporarily remove the src of the images and ask the user through a confirmation dialog.
You will also probably have to cancel the app cache update using:
window.applicationCache.abort() (documentation)
Reality
Unfortunately, the Net Info API is not available (at least not widespread) at the moment, but certainly will help in the future.
Long shot
There is a database that includes network speed (DIAL = dial up, DSL = broadband/cable, COMP = company/T1), but I haven't used it and I doubt it will help.
Dynamic App Cache
While checking into this, I tried to generate the html tag along with the manifest declaration on the fly, in order to combine it with the Network Info API but the AppCache manifest is loaded before javascript execution and is not affected afterwards.
So altering the manifest file on the fly through Javascript is not possible and data URI is not an option.
Alternative solution
HTML5 application cache is an untamed beast at the moment and there are talks to improve it. Until it changes to support more complex configurations (bandwidth level flag would be awesome), you could change perspective on the solution, although App Cache may be the best you have at the moment.
Depending on how big your images are you could rely on the normal browser cache. You could combine localStorage and far-future expiration HTTP headers. LocalStorage in order to keep track of the loaded/cached images.
First add a far in the future date for expiration on your images HTTP headers
On page load, remove all src from imgs
Loop the images and check localStorage if each image was loaded in the past
If there are images that were not loaded in the past, display a dialog confirming for the downloading of those images
If the image was loaded in the past, then put back the src on the img
For every image that is downloaded, save its URL on localStorage
I don't know what the status of indexedDB is on the iPad, but this could be an alternative solution.
In short: Indexeddb is a clientside database. Data is stored in object stores which are key/value pairs. The maximum storage capacity is in theory the maximum of your disk space. For more information about indexeddb:
Specification
My blog
What you could do with the indexeddb:
When someone navigates to a page:
Check every image tag if it is present in the indexeddb
if present
Get the image from the indexeddb and put it in the image tag
if not present
Download it
store it in the indexeddb
put the image in the image tag.
As extra (in the future) you can do as discribed by Sev: check the connetion type and only download the image when working on a fast internet connection.
I have 'invented' a working solution developing a webapp on the iPad (iOS 6.0.x) that may answer your question.
The idea is first to check if a localstorage variable is set/defined or not yet (I use the title of the page, thus the webapp name.)
If this localstorage variable exists, then assume (in webapp sandbox context) that its the first time the app is being run. At this point I populate a UUID in conjunction with $PHP_SESSION($uuid) to avoid 'cross app contamination' in server-side PHP land.
In addition to this I have a dynamic manifest.appcache.php which includes in the CACHE section a list of files to add to the manifest. Thus;
<?
echo $manifest_file_list[0]."\n";
?>
Using the JS appcache manifest event listeners I then monitor the progress to something like $('#manifestappcache').html(result);
I'm adding Box support to an iPad app. I tried the official SDK and I don't want to use it for the following reasons:
Login page is too wide for a modal controller with UIModalPresentationFormSheet style on iPad. The SDK hosts UIWebView which loads content of https://m.box.net/api/1.0/auth/, which perhaps returns HTML with min width set to 768px (although I didn't check the HTML, speculating here).
HTML in login page doesn't show Google Apps authentication option. The full desktop version of the page does.
Because the login page is hosted in UIWebView the user cannot be sure that he's supplying the credentials to Box, and not to an app author.
I don't need the whole SDK functionality, just authentication, folder/file listing and content download. Since my app also uses other cloud storage providers I'd prefer to provide uniform file browsing experience.
Here's what I'm going to do:
Add a custom URL scheme for my app, let's say "myapp".
In Box's Application settings for my app set Redirect URL to myapp://RedirFromBoxAuth.
When the user chooses to browse Box from inside my app, I'm going to:
Get a ticket by calling GET https://www.box.com/api/1.0/rest?action=get_ticket&api_key={API_KEY}
Extract the ticket, then call openUrl with https://www.box.com/api/1.0/auth/{TICKET} This will open Safari and let the user enter his credentials. This is the full, desktop version of the login page.
On successful login Box's server will tell Safari to redirect to myapp://RedirFromBoxAuth?ticket={TICKET}&auth_token={TOKEN}, which in turn will tell iOS to yield control to my app.
My app receives handleOpenURL notification and I can extract the authentication token and use REST API from now on.
Please comment, is it a good plan? I created a quick prototype and it seems to work, but maybe I'm missing something?
Box team, could you please tell us will an app using this authentication model be eligible for inclusion in OneCloud?
This seems like a good strategy and will probably make for a better UX/easier implementation than the normal redirect. Please let us know if you run into any weird edge cases by implementing it this way.