I have one app where users can create accounts and log in. Other apps will use this account to send in information on app usage.
As of now, users go from the normal apps to the login app via deep-linking, and they send their URL scheme to the login app, so the login app can return them afterwards using this URL scheme. A token is also sent back which is used to identify the user.
To get this to work the normal apps need an URL scheme in their Info.plist however. Logging in with Facebook or Twitter, this is not necessary.
Is there any way to do this without needing the URL Schemes in the Info.plist?
You could probably build a system to accomplish this using Branch deep linking with appended query param links and our match_guaranteed link parameter. That would let you pass data around without needing to hard-code the URL scheme into your client apps, because all of that configuration is handled server-side. It also covers you in the situation that one of the apps isn't installed.
I imagine it would look something like this:
Set up the 'master' app with a Branch key
Set up each client app with its own Branch key
Build an appended params link from the client app into the master app, including some sort of identifying token(s) for the client app. This token could even be the exact return link needed, which you can generate in advance
Do whatever you need in the master app with the sign in or registration
If successful, send the user back to the client app either by building an appended params link, or using the pre-generated link if you passed that over initially
Related
I have two separate apps that run against the same Firebase instance (db). I am adding email link authentication for them. The first one went well. I added the dynamic link domain to use (e.g http://one.page.link), and provided that in the iOS app as associated domain. When the email link is tapped it goes to the 1st app and logs in.
I started adding link authentication to the second app. However, when I send the email link, it references the same domain (http://one.page.link), and hence opens the 1st app on the device when tapped, instead of the second app. I would like it to send the link using a different dynamic domain (e.g. http://two.page.link), so I can associate it for the second app, resulting in the second app opening when it is pressed.
Is it possible to configure the dynamic link domain for the app?
Alternately, is there another way to achieve the same?
I was able to achieve it on iOS using a custom scheme to redirect to the right app based on the ibi or ipbi value in the firebase dynamic link.
Firebase still sends the same link. So, no change on server. On the client, if the ibi parameter in the url is another app, redirect to that app using a custom URL scheme to open the app. That app then reads the contents of the url and handles sign in if its for it.
We are developing an TYPO3 extension that is in charge of managing the social network profiles. We used the extension "ps_social" as a guide for understand the social media network APIs could work with TYPO3 through Adapter Pattern.
I have the proof of concept of the implementation to authenticate a profile and publish in it but through only in PHP, now we want to take it to the TYPO3 extension.
My question is about the callback when authenticating a profile. Our extension sends us to the social network and when we return to our web page, with the token in the url, this does not change and shows the same screen of the plugin before redirect to the authentication in the social network. The callback url in manage app in Twitter has the id of our plugin's page. I check url for change the plugin action but doesn't work.
We see that this step is fundamental to be able to later make publications to the authenticated profiles in the application.
The problem could be that your authentication service is not triggered when returning to the TYPO3 site. Whether or not your service will trigger depends on several configuration options. By default, your service will only trigger when a POST login action is taking place - but there are options to define that, for example, the authentication service must always attempt to fetch (and thus authenticate) the user even if there is no POST login data (instead, GET parameters may be used to determine if authentication should be attempted).
There is also a caveat if you intend to log in BE users using this method. I've noticed that if you attempt to log in a BE user in the FE, then no action or configuration will be respected unless an existing BE user cookie exists (which it will if you've ever been logged into the BE). If you use the authentication service to log in to the BE normally there isn't this problem - it only applies if you try to do it in FE.
TL;DR: I'm guessing you need to configure the "always auth user" setting for the targeted BE/FE context, using parameters described in the "advanced" section of this link: https://docs.typo3.org/typo3cms/Typo3ServicesReference/Authentication/Index.html
The problem was resolved creating a new plugin. In the configuration of application in Twitter I can not set parameters as controller and actions, for example; only the page id. I had to create a plugin in my TYPO3 extension that execute in one page the action for get information of callback, process and return the page with the list of social profiles. This We did it in each one social networks (Facebook, Google+ and Instagram) for their callback URL to be correct.
I would like to link to my iOS app from the Facebook main button of my business page.
However this seems very tricky.
This is from the documentation of Facebook:
https://developers.facebook.com/docs/applinks/ios
The example is in Objective-C. Does anyone have some guidance how to do that in Swift?
Assuming you have a URL scheme configured in your app, this actually doesn't require any additional code work to implement. Here would be the steps:
Go to your app page on Facebook and edit the button.
Under the iOS Settings section, open the dropdown menu and select App
In the next section, enter a URI using your app's custom URI scheme and a fallback website URL to use if your app is not installed (perhaps a page on your website, or a link directly to the iTunes store page)
Note: using the custom URI scheme only works acceptably in this case because Facebook is providing fallback functionality for another destination when the app is not installed. In any other place, if you opened your app's URI scheme without it being installed, you would instead get an ugly 'address could not be found' error. Obviously this is bad for user experience, so if you want to do conditional linking like this anywhere else, you can use a tool like Branch.io (full disclosure: I'm on the team) to handle it.
I'm trying to intercept link and login a user, then send them on to Safari and have the page load with no authentication request.
So, what I'm doing so far...
I register a custom URL scheme for my app. Call it "myhttp". Now someone clicks on a link (say from an email) of myhttp://secured.com/foo and my app runs. The apps pulls the user's credentials from somewhere and makes a call to the real URL with an NSURLConnection. The NSURLConectionDelegate implements connection:didReceiveAuthenticationChallenge and I navigate through the security layer fine. Next I try loading the same url using the UIApplication openURL method to bring up Safari, but I still get an authentication check.
I thought this would work because I read the follow in the Apple documentation.
Credentials stored in persistent storage are kept in the user’s keychain and shared among all apps.
And when I check the NSURLCredentialStorage I can see the credentials I just used stored there with the correct information, protection space, scheme, etc, but clearly I'm doing something wrong or I wouldn't be getting an authentication challenge when I switch to Safari.
So the question is, did I just screw up somewhere along the line, forget some important bit or am I going about this the wrong way?
This wasn't possible before iOS 8, but is now with the Shared Web Credentials feature.
Add a com.apple.developer.associated-domains entitlement to your app.
This entitlement must include all the domains with which you want to
share credentials.
Add an apple-app-site-association file to your website. This file must
include application identifiers for all the apps with which the site
wants to share credentials, and it must be properly signed.
When the app is installed, the system downloads and verifies the site
association file for each of its associated domains. If the
verification is successful, the app is associated with the domain.
An app can share credentials with any associated domains by calling
SecAddSharedWebCredential and SecRequestSharedWebCredential.
I have a need to set some context via Safari (a context token), and then read that context from a native iOS app. What are the best practices for doing this?
A couple thoughts so far:
Set the context in an HTML 5 database, but I'm not sure this will work because the database might be only accessible from Safari. Would using a WebUIView in the native app allow me to access the same HTML5 database / local storage as Safari?
Set the context in device storage, but I'm not sure this will work because I don't know if Safari can actually write to device storage.
I would suggest one of these two options:
Let the web server keep track on the user both in the app and on the website, for example by creating a user account.
or
Pass the context token to the app immediately via an URL-scheme by registering your app as a protocol handler, see more info here
Suggested way:
Send e-mail with link and context token, when user clicks link, save context token in cookie in safari, then redirect to appstore for app download.
When the user downloaded the app and opens it, present a button for the user, when the user clicks it, open a web page in safari.
Safari loads the cookie with the context token, and then triggers another link using a URL-scheme like yourAppName://contextToken=12345678. The link opens your app which reads the context token from the URL.
There is no best practice for directly sharing data between safari and a native app directly and that it is simply not intended that you should do that. All cookies and storages are sandboxed for each app and safari has its own sandbox.
Letting your server doing the job via user accounts is the best and clean way i.m.o. That is why you have user accounts. If you didn't try out the protocol handler for reading specific URLs, that could also be made handy I think.
Could you have the app hit a URL on first launch hosted by server which is redirecting the user in safari, and compare IP addresses, time, iOS version, etc to get at least an approximate match? If an approximate match is insufficient, you could, when you see an approximate match, have your app open safari to confirm their identify via cookie.
It’s easy to send messages between a UIWebView and your native up using WebViewJavascriptBridge.
In your case, though, the accepted answer’s suggestion of using a custom URL scheme (directly from email to app, post-install) makes the most sense.