I got a public mashup in my fiware instance. Is it possible to block the redirecting to the mobile site? (I think its not an url, I cant find a redirecting in the logs. Maybe some javascript code?)
And how does fiware/wirecloud determine if I'm using a mobile device or a desktop ?
WireCloud currently uses the user agent provided by the client to detect if the user is running on a mobile device. This detection is based on user-agents python module. This mechanism is specific to WireCloud, other FIWARE GEs can use other mechanism.
Finally, currently WireCloud doesn't allow you to disable the use of the mobile version in a general way. You can append a ?mode=classic to the URL (e.g. https://mashup.lab.fiware.org/alvaro-arranz-garcia/ckan-valencia?mode=classic) for forcing the use of the desktop version of WireCloud, but any user not using this modifier will get the mobile version when accessing from a smartphone.
Feel free to create a feature request :-)
Related
This is for doing OAuth with the Pocket API, it specifically states that using an embedded webview is a violation of the terms of use, all OAuth examples I can find on WP8 seem to rely on the embedded webbrowser to do the authentication.
Is it not possible to use the default browser in WP8 to do the authentication and then redirect back into the App? I have done this in Android before. Thanks.
Well, if you read their documentation, it says that you need to provide a redirect URL. I am not sure if it will work, but you could try adding URI association to your application and specify callback URL that will return back to your app.
Then, when your application is reactivated from the default browser, you should know that the user has authorized it.
Thus you could use WebBrowserTask for that, but I am unaware if you can call local app-URI from browser.
I am building a packaged chrome app (It is needed as I want to access chrome.socket). I have a website from which I would like to call my app (if installed or ask the user to install it) by clicking a link. Is this possible ? Not able to find any easy way for this workflow.
The url_handlers might be the best way to achieve this.
You can also use the externally_connectable manifest property to declare that your website can connect to your app, then call chrome.runtime.sendMessage or chrome.runtime.connect from your webpage and handle it in an chrome.runtime.onMessage handler in the app.
Which one is better suited depends on your needs. The url_handlers is an easier way, but it will permanently assign the URL on your link to your app, so you won't be able to use it for anything else if the app is installed. The externally_connectable is a harder way, but it enables a much more elaborate bidirectional communication between your website and the app.
You can even use a combination of the two approaches, if you need: launch the app using the url_handlers feature, then establish a communication channel back to the website once the app is up and running.
Apps can now (as of Chrome 31 I believe) register to handle urls by adding url_handlers in their manifest and detecting the url causing the app to launch in the chrome.app.runtime.onLaunched event. If the app doesn't launch, your hosted web site will be loaded an can present an inline installation with chrome.webstore.install.
Is there any way to authenticate the application to use the Google Drive API without a native browser in an embedded system?
I'm looking for a solution to the user accepts and put your password and username using the OAuth2.0 without browser interactions... Is it possible?
My applications is build in Java Code.
Thanks in advance.
I am presently trying to do just this and I don't think it is possible because:
To authenticate in embedded device you need to use this process:
https://developers.google.com/accounts/docs/OAuth2ForDevices
the problem with this, is that it only accept limited range of scopes like:
--https://www.googleapis.com/auth/userinfo.profile
which works OK
but when you try with scope like:
--https://www.googleapis.com/auth/drive.*
you get invalid_scope.
If you find a solution please let me know, I have the same problem my device is embedded, has no screen, and is not available with remote desktop of the like.
thanks for any feed back.
Use the OAuth 2 device flow which is designed for cases where a browser isn't available on the device. It allows the user to complete the login & authorization on a separate, more capable device (phone/tablet/laptop) where a browser is available.
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.
i know that the index.html page (the PhoneGap startup page) needs to reside on the device. but if we want to create an app who uses third party user authentication before proceeding to core application, so then what we have to do?
Thanks in advance
On android you can change the starting page in the main activity or you can make a redirect in index.html
Well, you don't say if you are platform specific..
And there are lots of third party auth options..
But I can offer two solutions (admittedly my own code etc),
both of them use PhoneGap for Android and PhoneGap Plugins. The key piece of code for me has been the onLocationChange callback feature of the ChildBrowser plugin. Your app can take the user to other sites for auth or whatever, but still get control back.
Tutorial on Using Twitter REST API (OAuth 1, ChildBrowser, jsOAuth plugin)
Free Android App + Source on github : AppLaud App (OpenID, ChildBrowser, custom server)
For authentication, you can have a form in your index.html (maybe under login div) to do a post to an actual webserver.
Then, fetch the data returned from the webserver to let your user access the functionality of your native phonegap application.
You can have the functionality disabled until you receive the successful login from the webserver. If you post via ajax, the webview won't even blink, but you will still get the successful login response from webserver and simply enable functionality on your app after this.
Let me know if this is confusing and I'll try to explain more clearly and
I hope this helps.