We are aware of this issue. At the moment, our developers are working on a solution to this problem. For now, I can suggest you to use api keys for this task(BKNDLSS-27504).
@sergey.kuk we have a webapp > mobileapp onboarding process, so we are using the Backendless system for a webapp where the user registers an account, and then the SDK on the mobile app to handle logins after that (some users may also register on the mobile app, but most will be webapp).
@mark-piller did you have any more thoughts on this? It’s quite fundamental to our app, if there is any way to solve this in the short term it would be very helpful.
is it possible for you to change the callbackURL in the code for my app in the meantime so that we can keep the current solution?
As a temporal solution you can try to disassemble authorization URL which you receive from the Backendless API, replace domain in redirect_uri link and assemble it back. It should work with all login providers except Twitter. Unfortunately it is the only way to resolve your issue at the current moment.
Could you give me more information how to disassemble the authorization URL?
And I am sorry I used the wrong terminology for the second question. I have been able to create the CNAME record, it is the A record that I need to point to an IP address to be able to point the other URLs to the main custom domain.
All what you need is to replace https://app.backendless.app by required protocol and domain. It can done by simple string replace.
Note. It is important to add your final URL from redirect_uri to “Callback URLs” section on the Google App side.
And I am sorry I used the wrong terminology for the second question. I have been able to create the CNAME record, it is the A record that I need to point to an IP address to be able to point the other URLs to the main custom domain.
Unfortunately I still do not fully understand your problem. There should be no problems with binding www.{your domain} to {your domain} as far as I know. Could you please provide more information about this problem?
It doesn’t re-direct the user to the secure website. From what I understand, the way to do this is to create an A record pointing to the IP address of the website, which I am unable to do with the Backendless custom domain system. Is there another way to achieve this?
Unfortunately my method will not work with UI Builder.
As for situation with domains, I can see that there is no problem for redirecting from http://www.customdom.com to https://www.customdom.com. It seems to me that the problem here that you try to redirect from root domain (customdom.com) to sub-domain (www.customdom.com). Usually the root domain specified as main and other variants configured to redirect to it.
Could you please try to make https://customdom.com main domain and redirect to it from all other variants?
The flow in general described here Social and OAuth2 Logins - Backendless REST API Documentation
You receive authorization URL (here you should make a change), open it in WebView or other controlled environment, wait till provider will redirect back to Backendless API and API responds with the JSON object. In this JSON object will be placed user info and user token for further authentication.
You can do it with any SDK which you prefer.
Speaking about domains. Checked your domain via whois. I looks like provider itself created A record for root domain.I will ask my colleagues about possible solutions for this situation.
About custom domains.
The only option for you is to create A record for your domain and point it to IP address of EU API 178.32.127.114. All other domain variants will point to your root domain.
But you should understand that this type of configuration is fragile one since Backendless API IP address can change in future. To prevent possible downtime for your site you should configure uptimerobot for your domain which will warn you when there are some problems.
Root domain DNS mapping (the one without www or any other prefix) is restricted by DNS, it is outside of our control. Our IP addresses do not change frequently, but it may happen as the cluster grows.
