I need to purchase a domain and hosting for my backend heroku rails server, so that I can implement SSL. (I could use heroku's SSL endpoint, but then I can't pin the certificate to my iOS app).
My question is... should I have my landing page and all my server side endpoints on the same domain?
For example... www.myexampledomain.com might be my landing page. Whereas www.myexampledomain.com/api/v1/things might be an endpoint returning json to my iOS client.
Should these be separate? Should I use subdomains for my json server returns? (I was hoping to use a single domain to save money on the SSL certificate)
Until you're server huge amounts of traffic, there really isn't any harm on having them on the same server. Even then, there are other ways of dealing with the traffic requirements other than separating the front-facing website from the API.
The pattern you showed is very common, and you shouldn't have any huge issues with keeping them together.
Related
My app allows users to create custom product landing pages.
I wish to setup this scenario:
Pages can exist on brand.myapp.com/offer-name, however I want to enable users to create landing pages using their own domain, for example brand.customerdomain.com/offer-name, which serves a page from my app.
I am unsure about the best way to do this. I know I can have users point a CNAME record to 'myapp.com', and then I add 'brand.customerdomain.com' as a Heroku custom domain. But is there a limit to the amount of custom domains I can add to Heroku? There will be thousands of these domains, so I don't know if this solution is feasible. I have had some success with this approach, however I get SSL browser messages when accessing the page from the user's domain.
In terms of SSL, I have a wildcard certificate installed on Heroku, for *.myapp.com.
Another way is to have a proxy server hosted elsewhere, and have users point a CNAME to something like 'proxy.myapp.com', which routes to my Heroku URL, however I haven't been able to get this to work on Nginx (on DigitalOcean), and haven't found any suitable guides (I don't have much Nginx knowledge).
The proxy approach I found here - https://mrvautin.com/enabling-custom-domain-for-saas-application-on-heroku/.
Cloudflare has a solution for this problem, however it's available to enterprise customers only, so I'd prefer to have my own solution - https://www.cloudflare.com/saas/.
What would be the ideal way to have multi-tenancy, with custom domains and SSL on Heroku?
I currently have my web application hosted on AWS, and I use two ELB instances, one to load balance the frontend requests to the app servers, and a second to load balance the backend requests FROM the app servers TO the API servers, like so (sorry for the crappy ascii diagram):
/-->APP1--\ /-->API1
User-->ELB1 ELB2
\-->APP2--/ \-->API2
In other words, the API requests that the APP servers make are load balanced evenly across the two backend API servers.
But, because I'm caching responses on the API servers, and use a cache invalidation mechanism which is NOT shared between the API servers, I'd like for a user's session to be stuck to one backend API server.
I already have the user's session stuck to one APP server, using the normal ELB load balancer-generated cookie stickiness, but is there any way to get the backend ELB stuck to a session? Of course, those requests are not coming from a browser, so there's nothing to manage cookies, and it seems that ELB's can only manage stickiness with cookies. Can I emulate the necessary cookies my backend requests?
To close off this question, yes, this is fairly easy to achieve by simply capturing the 'Set-Cookie' response header from the ELB, and then passing the cookie back in subsequent requests. But, see my caveat below.
I don't believe it would be possible to achieve stickiness between your App servers and API servers without doing a whole load of messy work. I could be wrong, and am very open to correction but I don't believe there is an easy solution, unless the language you're using for your App Server logic has something to offer.
Regardless, the best solution here would be to decouple your App Servers and your Cache. It would make more sense to have a single cache shared between the API servers that is served by separate servers. This will increase your infrastructure's fault tolerance and give you better quality data in your cache (especially as you scale up). You could use the ElastiCache service to do this for you and avoid any heavy lifting.
I'm at the beginning of trying to understand the requirements for developing a VoIP app. From what I've learned so far, frameworks that allow for communication using SIP/TCP are the best (I don't intend to implement SIP myself).
However, although SIP can be peer-to-peer, its recommended to use an SIP server service. But I'm finding it difficult to locate information about what SIP services are appropriate for an iOS application / what is required from me in terms of setup of the server so that I can concentrate on client-side development.
Any advice would be much appreciated.
You need to figure out your use-cases to decide. A SIP server is like an HTTP server, it will analyse the request URI, the request headers and whatever hints it can see to execute some resource at the backend. Think if you plan to have a user database and authentication. Do you want presence? Do you want voicemail, call transfers, pbx features? Do you want video, audio, IM? Do you want to support arbitrary endpoints? Encryption, NAT traversal, HA? Only then you can think about actual servers and hosting. Many "minimal" configurations will include at least one SIP/media front-end (for NAT/SBC), a SIP/media server (to act on requests), a database server (to store persistent state) and an HTTP server (for config/admin UIs). While there are products that combine some of these into single server, they are generally at least reasonably isolated modules.
Since many website will calling service by Web API. In that case, those methods will be exposed for every one. How can I ensure only my web site can calling my Web API service?
One of the easiest way to secure it as a developer is to get the IT people to do it by limiting access down by IP address from site to site. You could also do this in the app by validating the incoming IP addreseses. Sometimes IP addresses change sometimes they don't. Whenever I have done this have used certificates as there is a trust on both sides of the data divide. Have a look at John Petersens article Making web api's secure it has a section on implementing IP security in your app as well as x509 certificates; complete with code examples that I wont reproduce here. You could try and secure it with SSL and create your own key / trust but its easier to maintain (imo) using x509. Perversely it was much easier in the web service world Microsoft had an API to do this much more simple in WSE extension..
I'm currently building a mobile application (iOS at first), which needs a backend web service to communicate with.
Since this service will be exposing data that I only want to be accessed by my mobile clients, I would like to restrict the access to the service.
However I'm in a bit of a doubt as to how this should be implemented. Since my app doesn't require authentication, I can't just authenticate against the service with these credentials. Somehow I need to be able to identify if the request is coming from a trusted client (i.e. my app), and this of course leads to the thought that one could just use certificates. But couldn't this certificate just be extracted from the app and hence misused?
Currently my app is based on iOS, but later on android and WP will come as well.
The web service I'm expecting to develop in nodejs, though this is not a final decision - it will however be a RESTful service.
Any advice on best practice is appreciated!
Simple answer: You cannot prevent just anybody from acecssing your web site from a non-mobile client. You can, however, make it harder.
Easy:
Send a nonstandard HTTP header
Set some unique query parameter
Send an interesting (or subtly non-interesting) User Agent string
(you can probably think of a few more)
Difficult:
Implement a challenge/response protocol to identify your client
(Ab)use HTTP as a transport for your own encrypted content
(you can probably think of a few more)
Of course anybody could extract the data, decompile your code, replay your HTTP requests, and whatnot. But at some point, being able to access a free Web application wouldn't be worth the effort that'd be required to reverse-engineer your app.
There's a more basic question here, however. What would be the harm of accessing your site with some other client? You haven't said; and without that information it's basically impossible to recommend an appropriate solution.