Is it possible to use CloudKit Web Service from Android native app? How will that authentication popup window appear in a native app if I want to let user able to modify records?
Can I put a button to the native app, that will open up browser and the redirected content will appear there, and when authentication successfull, specify a callback where token which uniquely identifies users, I guess user record name can be received?
Apple engineer talks about login from web here on this session video: https://developer.apple.com/videos/wwdc/2015/?id=704
CloudKit Web Services is intended "to provide a web interface for users". If you use it to provide a native Android interface, you will probably get your iOS app rejected and lose your CloudKit access entirely.
But if you want to try it, Apple already has documentation for CloudKit Web Services which explains how to authenticate users.
From looking at the session video you mention, and also at the links and comments from Richard, I would say the answer is No to writing full native Android CloudKit apps. The reason is that Apple does not give you the option to enter the userID and password in your own dialog. The user can enter those only in a web window popped up by the apple code. So it seems at least that part of the app (authenticating the user) needs to be done using web code. I am not an Android programmer so perhaps it is possible to put together a hybrid app that addresses this issue.
Having said that, public database access does not require an iCloud account so you may be able to write an app that only uses access to the public part of your container using native Android code.
I am no expert but this is what I read on Apple website.
Use an API Token from a website or an embedded web view in a native app, or when you need to authenticate the user.
Maybe its like Netflix. Because Netflix iOS app looks just like netflix.com. To me it looks like netflix is using embedded web view. Maybe you can do the same with CloudKit.
Related
Please forgive my (perhaps naive) question, I am still a beginner!
I have a website on asp.net core that is essentially a CRUD website. There are some Razor pages and some controllers. When the user is logged in, they can create and update the data they own (through javascript and said controllers).
Login is organised via Cognito's built-in UI. I redirect the user to it with the [Authorize] attribute on certain controller actions. The token (I think this is what it's called?) coming from Cognito is automatically stored in the browser cookie and is passed between the browser and the backend (controllers and Razor pages). In the backend controllers and Razor pages, I have very convenient methods like User.IsAuthenticated(), and can get claims and fetch cognito:username and similar fields.
The website is working well enough.
I am now working on native mobile apps (Android and iOS), and I am wondering how to deal with authorisation in them as well. I want the user to have the same experience in the mobile app as on the website: they would log into the mobile app and see and edit the data they created earlier on the website, and vice versa. I'm not sure how to implement this correctly. I see several options:
Option 1. Use the AWS amplify framework in the apps. I am sure it will work nicely; but how will I then pass the token to my backend controllers? Asp.net core needs it to build this User object, I understand. I think asp.net core stores it in the cookie appropriately named .AspNetCore.Cookies, but I'm not sure as to its format and whether it'll stay stable in the next releases?..
I'm currently reading about JWT bearer tokens, maybe that's the thing that should be used instead of .AspNetCore.Cookies?..
Option 2. I could "pretend" that the mobile app is the same as the browser and send exactly the same requests as my web frontend does. I suppose this sounds very complex - I'd need to store cookies, follow redirects (to the cognito built-in ui, for example) - I don't know if there is a built-in mechanism? However, in this case the app doesn't have anything to do with cognito, talks only with my backend, and is just following redirects. AppAuth states that Authorizing the user occurs via the user's web browser, so perhaps it can be used here?
Perhaps there are other options that I overlooked; I'm almost sure there is a simple solution I just can't see at the moment. Sorry it's all over the place, this is a very new topic for me. Thank you in advance!
I have a web based service (running for years) that works with google apis.
Now I would like to create an android and iphone ui (using xamarin) that uses my web services which in turn talks to google apis.
Given that I don't talk directly to google apis from the phone, do I need to use a web browser control to let the user login, or can I authenticate my server and establish a session natively on the phone?
I'm afraid I need to use a browser window, and I don't think it's user friendly to have to login to a google account in a browser window on the phone.
(I want to keep the logic on the server, so that the phone apps and the web ui uses the exact same code for it's calculations.)
EDIT: It seems Cross-client identity is what I'm looking for.
It can be done natively. See this video https://www.youtube.com/watch?v=9wAx39s10yw which explains all of the procedure using cross-platform authentication.
I want my app users to be able to share one of the app pages to others as an external web link as a good marketing strategy, so people who don't have the app can view this page and get excited hopefully to download and register although no one can view the app without signed in, for now I have the app and its web domain I didn't build the website yet, What is the efficient way to do so ?
You can write some code on the server to receive the data, store it and then serve it back (php/mysql or java or anything else). The easiest way to do it is to make a form and to send a request from the android app to simulate a filled-in form.
You could also just publish to Facebook or Google+, there are APIs to do that from and Android app.
This question is specific to Native mobile applications (e.g. IOS, Android, WP apps that are not actually using a browser to access a web site).
We have an existing e-commerce website that takes payment for most of the major credit cards, and it also performs payer authentication via the 3DSecure program (implemented as Verified by Visa and MasterCard SecureCode). This helps negate fraud and reduce charge-backs.
The existing implementation is such that during checkout and payment stage, it involves redirecting the customer away from your website, to a bank / card issuer website where the customer can enter their previously set-up password to authenticate that they are indeed the card holder. The website will then redirect the customer back to your website with information needed to complete the transaction. (There is quite a bit more to it, but that's the basic premise of it).
So we're working to create a native app for IOS (initially) that is not just the user browsing with Safari to the website, but an ObjectiveC implementation that gives a native experience that is rich and task focussed UI and easy for the user to operate.
What we cannot do is open 'n browser window from the native app for the user to be redirected somewhere, for authentication, and then redirected back. The reasons for this are:
This is a native app, not a web site, so there is nowhere (URL) to redirect back to.
The user experience is terrible switching from a clean UI to a squinty and differently styled web form on another website, and then back.
Has anyone had to try and implement 3D Secure (VbV / SecureCode) using a Native app (WP/IOS/Andriod)? Can it be done? Did you take a different approach?
Thanks for reading!
Even in native app you should use embedded WebView component to open banking ACS server url, let user enter password or other code there, get it verified by the bank and get back the results for your app for further forwarding to your card processing api.
As for Android, you can take a look how it is done in my helper class - https://github.com/LivotovLabs/3DSView (after making a couple of apps with 3D Secure support I decided to create a micro component for such task)
Hope this helps
We made an early decision with our acquirer (Global Payments aka HSBC) to not implement 3DS on native apps (or even mobile website in the end) because of the terrible user experience. We've had no problems with chargebacks, or with users. You should speak to your acquirer about this, and also to your payment gateway - in my view you should have 3DS switched off for mobile native / web until it is proven. Otherwise customers will not complete transactions.
That said, companies like Mopowered are claiming to have solved this with better implementations. I haven't seen these yet.
You can solve the 3d-secure redirection problem by using custom url-schemes. This is not a good user experience as you said, but we solved it this way on our ios project.
As others have mentioned, the shopper's experience during native authentication will be too poor to consider implementing.
However, with the introduction of 3D Secure 2.0, 3D Secure providers will be able to offer native SDKs to allow authentication with less abandonment rate.
If I am building an Android app that uses the Facebook SDK and also has a web app that has most of the same functionality, how should the Android app handle social actions? Should it directly make requests to the Facebook API through the SDK or should it post to the web app server through my own API and allow the web-app to make the request to Facebook on behalf of the Android app? Most of the Facebook for Android examples use the former approach however none explicitly discuss the best practice when there is a web backend that will have the same social functionality as the Android app.
I've been putting my mind into a similar problem before. It was a PHP app, but essentially the design choice was to either put the FB-interaction into the frontend (JS-SDK) or into the backend and proxy it (PHP-SDK). Sadly haven't found much guidance either, so I had to make up my own mind.
As so often there seems no per-se answer, it depends on what you are doing with FB and how deep it is integrated into whatever your app/webapp/backend are doing. Is your Android otherwise more a client-side app or does it rely on other features delivered by the web-app via web-service? Is it somehow integrated with users actions that are dispatched to the backend, or does it just offer some additional gimmicks (e.g. 'Like' button, anything in the lines) Are you using the SDK to authenticate and pull user related data from FB (email, name) and does that information play a role in your backend?
As I see it, it boils down to the following:
Direct communication with FB is a lot simpler to implement as you won't have an additional layer between your app and FB, i.e. proxy code, etc. So if FB is just loosely coupled it's likely the 'good-enough' option.
Patching FB from frontend to backend can get nasty - especially if you want to authenticate via FB it's kinda complex at first. However, you'll have all FB logic in a single place, shared by Android-App and Webapp, so it's obviously easier to maintain later and better to integrate with other interactions your backend might be offering.
Hope that provides some value, would be eager to see other opinions too.
Well I think both approaches are correct but the choice depends on mostly what you already have in place on the server side and if you are planing to use the same functionality from different apps like (Android,iOS, Windows Phone apps). In that case it makes sense to just get user token with permissions you require on the front end and let the web server talk to facebook using that token. You could even save this token for the user so they don't have to give permissions again if for example you have web registration and app registration. In our app we are using this approach since there are basically five front ends (Android,iOS, Desktop,Mobile Web,Full Web) this way application developers just get token using sdk on there platform (you have to use tokens and not user name, password because of facebook rules for security). On the other hand if all Facebook communication is used only inside your app and the server doesn't need to know much about it put api calls in the app.
In my opinion, it is best to use the available SDKs/APIs for each given platform instead of trying to write your own centralization and use a single library. Since you are specifically interested in how the Android app should handle social interactions, I suggest using the Facebook SDK for Android.
While it does increase the size of the code you must maintain and the SDKs/APIs you must learn as your list of platforms increases, the most important factor for this approach is the user experience. By sticking with the native libraries, and growing your app as those libraries evolve, you will be providing your users with an experience that they are most likely to be used to. They won't have to learn how to use your app, but will be able to make posts, update their status, and look at their friend list using controls that they are accustomed to using. Additionally, you will be able to take advantage of specific platform functionality (in the mobile case, such as having your app post to a users feed in a way that promotes your app: https://developers.facebook.com/docs/tutorials/androidsdk/3.0/games/feed/)