We have a windows phone native app (and building for android, iOS also) which uses ADAL to get token for ex:graph. ADAL is asking for credentials for the first time.
Now inside of this native app on some frame we have a WebView control which launches another website (our own) or say login.microsoftonline.com which is asking to login again. How can I achieve SSO in this case and don't prompt login for the second time. Is there a way I can reuse the same WebView control which ADAL is using so the cookies will be shared. What are the alternatives in achieving this.
ADAL on Windows Phone does not use a WebView. It uses the WebAuthenticationBroker (WAB), a system API specifically designed to keep the cookie jar used during authentication isolated form the app itself. That prevents apps from using cookies to silently access protected resources without the user knowledge, while at the same time pooling the cookie jar across all the apps that use the WAB for authentication.
Furthermore: there is no native app to browser SSO mechanism today.
Hence, as of today there is no way of sharing SSO state between the app itself and a WebView hosted by the application.
Related
I've followed this doc to
Create a wrapper Android app based on this sample project for my UI application which runs in non-public domain in our corporate servers.
Add assetlinks.json in my Angular 6 PWA application, with SHA256 fingerprints of my release key.
Deployed the signed apk to a Android 4.4.3 device running Chrome Dev 69 and Google play services - 12.8.74.
When I run the application, everything works fine except hiding the address bar, which makes it as a regular custom tab and not the "Trusted web" content.
I don't see any error in the log and not sure how to debug this scenario. Any help on this is appreciated.
Got confirmation from Chrome team that they are using TWA assets link validation in server side using an API call and so this solution wont work for Private web apps. Said that, they are also considering to move that logic to browser to support this use case. Will update here when I have any update on this.
Update: As of Chrome Version 72, TWA(Trusted web activity) if available in Chrome stable version and the web asset validation(to make sure the web page is yours/same as the app its loaded to) happens in browser. So this solution can be implemented for private web apps for hosting inside enterprise environment.
Also, now PWAs can be packed as regular app using TWA solution and uploaded to Play store as an apk file. Documentation on this is still being updated as per one of Chrome developer. But the solution as such is ready for use.
Understandably, PWAs (Progressive Web Apps) are added to home screen after the user visits the web app in a supported browser and clicks on "Add to Home Screen". This works fine for publicly available PWAs.
Thinking of Enterprise Android applications, which needs to be installed to thousands of devices via some app push tools like Airwatch, its practically not possible to have someone open the browser, put the URL and then add to home screen in all thousands of devices.
Is there any other way to automate this deploy/add icon to home screen of a Progressive Web App, not needing the user to visit the web app in a browser, and clicking on "Add to Home Screen" ?
One option we thought about is wrapping in Cordova, but we're trying to find a solution without such wrapper.
Chrome for Android generates and signs .apk file on the fly using WebPack, when the user clicks on "Add to Home screen" (from menu or install banner) option and if the site has a valid manifest.json and service worker.
Extracting and distributing APK: This .apk can be located and exported to desktop using file explorer tools. For some reason, some of default file explorer tools couldn't locate this .apk file. Once exported, this .apk can be used to distribute in controlled environment..like in enterprise devices, where you can enforce the deceive to have Chrome Browser. If this .apk is installed to devices which don't have Chrome browser, user will get a message saying "Chrome" is required to open this app. Once installed, installed PWA apk can be used.
For distributing PWA apps through Play store, google is streamlining the process. A google engineers repose on building APKs (March-2018), when we reached out to them for our enterprise needs.
"Well done extracting the APK and deploying it, it should give a good experience to end users, but I agree it shouldn't be that complicated to deploy web apps on Android.
We are currently working on a streamlined web apps feature, with which you wouldn't need to manipulate or build APKs. This feature will be available on managed devices using Play to deliver apps"
Alternate options: If you think your user base may not have Chrome or don't want to rely on that dependency, wrapping with Cordova kind of hybrid solution is the only way to build your PWA apps for distribution in app stores. With this option, if the "webpack" in the device has the version 40+, user will get PWA benefits. Otherwise, it will still work as a regular hosted web app.
Update on TWA - Trusted web activity is the official way to pack PWA for Android and its available in Chrome 72 and it also supports private/enterprise web apps as the digital assets validation happens in browser now(it use to happen in cloud, making this solution not possible for private web apps).
You can upload the PWA to Playstore using tools like PWA2APK. Just need to share the play store URL to the users, from which they can download PWA app like normal Android App.
Trusted Web activities are a new way to integrate your web-app content such as your PWA with your Android app using a similar protocol to Chrome Custom Tabs.
Trusted Web activities
I have an app made in xamarin (for Android, iOS and Windows Phone) which requires deep linking which should open and internal page on receiving an url.
This url will be sent by sms to the user with http protocol. I tried the solutions provided by OneLink and Branch Metrics and they work with Android and iOS. The only problem is with Windows phone (8.1).
Both of them are not able to detect if windows phone is installed and if yes open the app and not take to the store.
Is there any solution to this (maybe third party solution).
NOTE: i have tried directly clicking myapp://open and it works on windows phone but what i need is using http and not my app as the above custom protocols are non clickable within Sms's.
Yes, deep linking is possible on Windows Phone. Shortcut Media offers a third-party solution for this (disclaimer: I work for Shortcut Media).
Have a look at this answer to see how to implement it manually...
I am trying to build an extension that interacts with certain webpages. While browsing on those webpages i need to connect to a smartphone app via Bluetooth if the user wants to run a certain function of the extension.
AFAIK Chrome extension can interact with websites while Chrome apps are like stand alone programs. But the Bluetooth API is only available to apps?
So is there any way to do this? Can I for example have a hybrid of an extension and an app? (e.g. by using the same background script to communicate)
You can use an extension AND an app that talk to each other with external messages. A message from an extension will wake up the app's event page even if it's unloaded. It will be up to the user to install both at the same time, though.
Alternatively, you can embed a browser page in your app via the <webview> tag. In this case you can communicate with the embedded page, but you can't do it while user browses normally.
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.