I'm quite new to backend dev, and Google cloud seemed like a good option for hosting a Golang API for an iOS app.
Recently app started requiring that the app should be accessible in a IPv6 only environment, and I was wondering if Google Cloud App Engine can provide me with that.
Thanks in advance!
Yes, a blog post in 2010 the GAE team stated
The Google over IPv6 program allows ISPs with good connectivity to request IPv6 access for most Google services. In about a week, we'll be adding Google App Engine and the appspot.com domain to this program. This means that all App Engine apps will become accessible over IPv6 to anyone participating in the program!
For most people, this won't require any changes to your code at all. If your App Engine code reads os.environ["REMOTE_ADDR"] in Python, or HttpServletRequest.getRemoteAddr() in Java, be aware that this value may be an IPv4 address, like "192.0.2.1", or an IPv6 address, like "2001:db8::1". Now is the time to verify that your code doesn't make any IPv4-specific assumptions, so that your IPv6-ready users will have a seamless transition.
Related
I followed the tutorial on learnforge.autodesk.io and was able to create a functioning app that accesses data from Construction Cloud and displays them using Forge viewer. The problem is, I'm not able to access Autodesk's login screen behind a firewall (which usually happens when sales team visits a client's office).
For what it's worth, I'm using ExpressJS for backend and have HTTPS enabled. The firewall at client's site also blocks access to virtual machine services like Parsec.
I don't even know exactly what the problem is (or how to troubleshoot), all I know is that this login link:
https://developer.api.autodesk.com/authentication/v1/authorize?response_type=code
&client_id=<client_id>
&redirect_uri=<callback_url>
&scope=<scope>
doesn't work behind a firewall (it works fine through mobile data hotspot though).
So is there anything I can do on my end to make it work?
If that's not possible, what must the client do in order to access my app from behind their firewall?
Apple rejected an app because it didnt work on their IPv6 network. I've managed to test this on my end using an ipv6 only address and can see that the third party API i'm using is unreachable when using an IPv6-only address.
Any time i try to use the API I get the response
A server with the specified hostname could not be found
The same thing happens if I manually go the URL in safari, whereas other IPv6-ready sites like gmail etc work.
So my question is do I need to get the developers of the API I'm querying to update their servers to support IPv6 in order to get this working, or is there something I should be doing on the app side in order to make this work?
There's no need to change any external servers. It's all about the client. If by this "third party API" you mean they have a library which you include into your app, then perhaps they are doing something in their code that is not working correctly; if this is the case, then you need to ask them to fix their client library.
So my current task at the company I'm interning with is to create a mobile version (iOS) of a web app written using Flask, HTML & CSS that currently exists and is being hosted on AWS's EC2. Assume I'm a complete noob at AWS and only just learned that EC2 is a cloud computing service.
Essentially, I just want to be able to reflect what's currently on EC2 over to a mobile app in a secure fashion. I guess I'm just trying to avoid rebuilding something in Swift that's already been done. For those familiar with WebView in Xcode, I tried to use that to reflect the web page, but it didn't work (I assume because our web app on EC2 requires login credentials when you open it in a browser?).
I thought that maybe using AWS's SDK for iOS would net me some luck, so I installed cocoapods and setup a pod, but don't know how or which of these AWS services will help me achieve what I'm trying to do (from reading the documentation, it seems like their purpose is for building an app, not necessarily just projecting a webpage with data already in it).
For some more information, some key features that I think would be useful for our clients that would be using the app are:
The ability to persist data on the app when their device is offline
Some sort of temporary logins for the users. This app wouldn't be distributed through the app store; it would probably just have to be locally downloaded onto certain clients' devices
Lastly, I saw this post come up before creating this one: Does REST API for mobile apps hosted on https protocol web app will be slow? and I noticed that the asker of this question said "Lets say I have built a mobile app running on Android and iOS platform and REST API's for these apps lie under https based web application." This possibly sounds like something that could be helpful, and if anyone could explain what s/he meant by REST API's and what they are, I would be very grateful.
Any advice on how to proceed from here, using anything, would be much appreciated. Thanks!
I've seen in a few tutorials that Google's Places Web Service API is prohibited from being used directly from a mobile device. Is this still true?
I wouldn't call it easy, but after setting up a server key without any restricted IPs/Referrers, it seems to function just fine for me. I have searched quite a bit for official documentation from Google that specifies this to be the case, but I have yet to find anything concrete. I could see it being a good idea for additional security, but is it a requirement?
The Places API Policies document has a section Mobile Applications, but doesn't mention any restriction regarding using web service directly from a mobile device.
https://developers.google.com/places/web-service/policies
I have seen other questions on SO about this (here, here, and here), but I am not satisfied with any of the solutions, so I am asking it again. I am starting a web application that will utilize OAuth from multiple providers (Google, Facebook, Twitter, Yahoo) for authentication. I am struggling to find a configuration suitable to use for both a local development environment and a production environment.
The leading solutions I've found are to register multiple apps within each provider, receiving a different consumer key and secret for each:
"My App Production" - with a callback URI to http://www.myapp.com/callback
"My App Development" - with a callback URI to http://local.myapp.com/callback
Add an entry to your local hosts file to point local.myapp.com to 127.0.0.1 and some configuration for your application to use the proper consumer keys based on the environment, and you are good to go, right?
But my application is responsive and I need to test my development environment running on my PC from multiple other devices, like my iPhone and iPad, neither of which will be able to resolve the development callback URI.
Let's say I already have a DNS server on my network and am able to add the entry for local.myapp.com there instead of my local hosts file and can now access my development instance from any device on the network.
But my development team all operates on the same local network. Now local.myapp.com points to the same IP for everyone. Let's go back to setting the hosts file on each developer's computer so that they can all work independently from within their workstation. Now no one can test their development instance from their iPhone again. It hardly seems like the right answer for each developer to register an application with the provider just so they can specify a unique callback URI.
Normally when I get way down in the weeds with a complicated solution for a seemingly straightforward issue, it usually means I'm doing something fundamentally wrong. Am I missing something about OAuth, is it not intended to be used like this? I am tempted to scrap OAuth altogether and just go with OpenID (no app registration required and can specify the callback URI from within the app), but then I lose two of the big hitters in Facebook and Twitter. I don't really need any of the user's data, it's just a nice to have if it's available. Can someone talk me back into OAuth?
I can't speak for FB or Twitter, but in Google's Oauth implementation you can register several oauth callback URLs. So you simply need some logic in your app which senses that it is in test mode, and then starts the Oauth flow with the appropriate callback URL. There are downsides, eg clashes between the live and the test refresh tokens, but they are manageable.
In my app I have a singleton which manages all of this. When my app needs to start an Oauth flow it calls the singleton with the request URL and any other salient data (eg. debug flag) and the singleton returns the correct callback URL, client ID etc.
I posted the following answer about a rails app I wrote:
OAuth2 in development and production
It was a gem called figaro which did per env configs for google OAuth2.
I have yet to find a less manual approach that enables dev access to all concerned devices:
Assign each developer's machine a fixed IP through the local network's DHCP system based on their MAC address, or (less recommended) have them choose an IP and hope for the best
(optional*) Assign each developer's machine a DNS hostname in the local network based on that IP
Register an oauth entry for developer on each provider with the hostname of the developer's machine.
Each developer configures their application to use their unique oauth dev tokens.
Assuming all the devices in the network rely on the same DHCP and DNS servers you'll then be able to visit alice.dev.myapp.com or bob.dev.myapp.com from any device on the network.
Note, you'd manage the oauth configuration for each an every other environment separately, but following the same approach.
There are likely tools to automate registering a developer's machine IP and hostname to ease that part of the puzzle. Registering the oauth config on each provider per dev is the most tedious step.
UPDATE
*You can skip the DNS part if you use a xip.io url e.g. 10.0.0.123.xip.io if you know Alice is 10.0.0.123, but you'd still want that IP to be fixed as you don't want to keep updating the url for the oauth tokens in step 4.